Subject: RE: RE: AAAEXT charter, Take 1
From: "Kuntal Chowdhury" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 31 Mar 2004 15:06:50 -0600

John,

>MIPv6 was not designed to interwork with MIPv4, so if someone 
>tries to mix them, I am sure they will find problems.
>

Not sure why you think "simultaneous deployment" means mixing two protocols!
This is not a MIP thread, therefore I would not debate over MIP issues
anymore.

>> I don't want to see a repeat of what happened in MIP WG in this 
>> planned WG for RADIUS.
>
>But I am concerned because Diameter was designed to interwork 
>with RADIUS. If the WG goes of and extends RADIUS in ways that 
>destroys the interworking, then we have a big problem.  
>

I will be perfectly alright to add a sentence in RADEXT charter to say that
the work done in this WG shall not destroy interworking with DIAMETER. I
believe that will address your concern.

-Kuntal

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 20:54:15 +0000
content-class: urn:content-classes:message
Subject: RE: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 23:52:35 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Kuntal,

> You may be right, however there are carriers who already use MIP4 and =
plan
> to deploy MIP6 in near future. We cannot guarantee that MIP4 and MIP6
> simultaneous deployments will not discover issues.=20

MIPv6 was not designed to interwork with MIPv4, so if someone tries to
mix them, I am sure they will find problems.

> I think the main reason for MIP WG split was that the MIP WG had split
> everything, e.g. split audience, split priorities etc. I recall the =
meeting
> where the WG decided to break into two separate WGs citing these =
reasons.
> Another reason was the delay in getting things done for MIP4 due to =
huge
> amount of time and resource allocation for MIP6. One example is: 3GPP2 =
still
> uses RFC2002 because the updated RFCs had several bugs and the MIP WG =
was
> too busy with MIP6 and had no time to rectify these MIP4 bugs.
>=20
> I don't want to see a repeat of what happened in MIP WG in this =
planned WG
> for RADIUS.

But I am concerned because Diameter was designed to interwork with =
RADIUS.
If the WG goes of and extends RADIUS in ways that destroys the =
interworking,
then we have a big problem. =20

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 31 Mar 2004 20:28:10 +0000
Message-ID: <[email-masked]>
From: "Kuntal Chowdhury" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 14:25:26 -0600

John,

You may be right, however there are carriers who already use MIP4 and plan
to deploy MIP6 in near future. We cannot guarantee that MIP4 and MIP6
simultaneous deployments will not discover issues. 

I think the main reason for MIP WG split was that the MIP WG had split
everything, e.g. split audience, split priorities etc. I recall the meeting
where the WG decided to break into two separate WGs citing these reasons.
Another reason was the delay in getting things done for MIP4 due to huge
amount of time and resource allocation for MIP6. One example is: 3GPP2 still
uses RFC2002 because the updated RFCs had several bugs and the MIP WG was
too busy with MIP6 and had no time to rectify these MIP4 bugs.

I don't want to see a repeat of what happened in MIP WG in this planned WG
for RADIUS.

-Kuntal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Wednesday, March 31, 2004 2:02 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: [email-masked]
>Subject: RE: RE: AAAEXT charter, Take 1
>
>
>Kuntal,
>
>> Why overloading RADIUSext with DIAMETER issues? If 
>discussions happen 
>> separately, folks who have very little interest in pure RADIUS won't 
>> have to deal with volumes of email on RADIUS. Take the example of 
>> Mobile IP WG. The WG was split into MIP6 and MIP4 because it became 
>> too chaotic to manage and progress work on different 
>disjoint threads.
>
>Because MIPv4 and MIPv6 don't interwork in any current deployments.  
>RADIUS and Diameter will need to interworking in many deployments.
>
>John
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 20:04:19 +0000
content-class: urn:content-classes:message
Subject: RE:  RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 23:02:09 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Kuntal,

> Why overloading RADIUSext with DIAMETER issues? If discussions
> happen separately, folks who have very little interest in pure=20
> RADIUS won't have to deal with volumes of email on RADIUS.
> Take the example of Mobile IP WG. The WG was split into MIP6 and=20
> MIP4 because it became too chaotic to manage and progress work
> on different disjoint threads.

Because MIPv4 and MIPv6 don't interwork in any current deployments. =20
RADIUS and Diameter will need to interworking in many deployments.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 31 Mar 2004 19:44:01 +0000
Message-ID: <[email-masked]>
From: "Kuntal Chowdhury" <[email-masked]>
To: Greg Weber <[email-masked]>
Cc: [email-masked]
Subject: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 13:43:14 -0600

With all due respect, I don't agree that the discussion in this planned
WG will be protocol agnostic. Also, I believe separate WG atleast for 
RADIUS will be a cleaner/faster way forward. If needed this WG can be
rechartered to include DIAMETER issues in the future only after the time
when work on the urgent RADIUS topics subside.

-Kuntal

>-----Original Message-----
>From: Greg Weber [mailto:[email-masked]] 
>Sent: Wednesday, March 31, 2004 1:28 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: [email-masked]; [email-masked]
>Subject: Re: AAAEXT charter, Take 1
>
>
>> 
>> Why overloading RADIUSext with DIAMETER issues? If 
>discussions happen 
>> separately, folks who have very little interest in pure RADIUS won't 
>> have to deal with volumes of email on RADIUS.
>
>On the contrary, i would imagine that most of the _issues_ are 
>AAA issues and not specific to the protocol.  Protocol 
>selection seems to be almost more of a deployment/OPs issue 
>rather than functional at this point at least.
>
>> Take the example of Mobile IP WG. The WG was split into MIP6 and
>> MIP4 because it became too chaotic to manage and progress work
>> on different disjoint threads.
>
>Which contrasts with DHC where DHCPv4 & v6 are both handled by 
>the same WG....
>
>Greg
>
>> 
>> -Kuntal
>> 
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]]
>> >Sent: Wednesday, March 31, 2004 11:51 AM
>> >To: [email-masked]; [email-masked]; 
>> >[email-masked]
>> >Subject: RE: AAAEXT charter, Take 1
>> >
>> >
>> >Hi Avi,
>> >
>> >> Is the scope of work going to remain the same?
>> >
>> >My feeling is that the scope would basically be the sam.
>> > 
>> >> If not, how do limited resources get mapped between 
>> >> RADIUS/Diameter?
>> >
>> >I would have resources if RADIUS and Diameter compatibility is
>> >included. I have less interest in pure RADIUS.
>> >
>> >John
>> >
>> >--
>> >to unsubscribe send a message to
>> >[email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 19:29:24 +0000
From: Greg Weber <[email-masked]>
Subject: Re: AAAEXT charter, Take 1
To: [email-masked] (Kuntal Chowdhury)
Date: Wed, 31 Mar 2004 14:27:52 -0500 (EST)
Cc: [email-masked], [email-masked]

> 
> Why overloading RADIUSext with DIAMETER issues? If discussions
> happen separately, folks who have very little interest in pure 
> RADIUS won't have to deal with volumes of email on RADIUS.

On the contrary, i would imagine that most of the _issues_ are
AAA issues and not specific to the protocol.  Protocol selection
seems to be almost more of a deployment/OPs issue rather than
functional at this point at least.

> Take the example of Mobile IP WG. The WG was split into MIP6 and 
> MIP4 because it became too chaotic to manage and progress work
> on different disjoint threads.

Which contrasts with DHC where DHCPv4 & v6 are both handled by
the same WG....

Greg

> 
> -Kuntal
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] 
> >Sent: Wednesday, March 31, 2004 11:51 AM
> >To: [email-masked]; [email-masked]; 
> >[email-masked]
> >Subject: RE: AAAEXT charter, Take 1
> >
> >
> >Hi Avi,
> >
> >> Is the scope of work going to remain the same?
> >
> >My feeling is that the scope would basically be the sam.
> > 
> >> If not, how do limited resources get mapped between RADIUS/Diameter?
> >
> >I would have resources if RADIUS and Diameter compatibility is 
> >included. I have less interest in pure RADIUS.
> >
> >John
> >
> >--
> >to unsubscribe send a message to 
> >[email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 31 Mar 2004 19:19:37 +0000
Message-ID: <[email-masked]>
From: "Kuntal Chowdhury" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 13:18:31 -0600

Why overloading RADIUSext with DIAMETER issues? If discussions
happen separately, folks who have very little interest in pure 
RADIUS won't have to deal with volumes of email on RADIUS.
Take the example of Mobile IP WG. The WG was split into MIP6 and 
MIP4 because it became too chaotic to manage and progress work
on different disjoint threads.

-Kuntal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Wednesday, March 31, 2004 11:51 AM
>To: [email-masked]; [email-masked]; 
>[email-masked]
>Subject: RE: AAAEXT charter, Take 1
>
>
>Hi Avi,
>
>> Is the scope of work going to remain the same?
>
>My feeling is that the scope would basically be the sam.
> 
>> If not, how do limited resources get mapped between RADIUS/Diameter?
>
>I would have resources if RADIUS and Diameter compatibility is 
>included. I have less interest in pure RADIUS.
>
>John
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 19:10:30 +0000
Date: Wed, 31 Mar 2004 14:04:09 -0500
To: Radius Extensions <[email-masked]>
From: David Mitton <[email-masked]>
Subject: Re: AAAEXT charter, Take 1

On 3/31/2004 07:58 AM -0800, Richard Perlman wrote:
>On 3/31/04 07:51, "Bernard Aboba" <[email-masked]> wrote:
>
> >> For what its worth, I agree with Jari's suggested modified charter.
> >> I have more interest in the converged view of supporting both RADIUS
> >> & Diameter, so I'm motivated by Jari's charter to be involved.
> >
> > How do other participants feel about a "AAAEXT" charter?
> > Should we rename the potential WG and re-orient towards handling both
> > RADIUS and Diameter in a single WG?
> >
>Bernard:
>
>Personally, I'd like to keep the work separate.  There is certainly good
>reason for the work on DIAMETER and RADIUS futures to coordinate with each
>other, but I think the actual WGs should be separate.
>
>One good reason is to avoid endless battles over whether a certain extension
>should be in D, R or both.  Let each group work out the best path, that is
>consistent with overall IETF/IESG direction.
>
>Richard

The consistent IETF/IESG direction has been to prevent any further RADIUS 
development. That is why the RADIUS WG closed.  That is why we created the 
NASREQ WG and later the AAA WG.

I think the idea of a group that attacks the AAA problems and comes up with 
solutions for both Diameter and RADIUS is the most politically, and 
functionally desireable.

Dave. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:57:06 +0000
content-class: urn:content-classes:message
Subject: RE: RE : AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 20:53:21 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Lionel,

> If there is a proposal for enhancing the current NASREQ=20
> application for LAN/WLAN (with a new command or new madatory=20
> AVP for instance), would it be now considered as possible=20
> work item? I know that the goal is to narrow as much as=20
> possible the scope of this working group on RADIUS extensions=20
> but reading the first part of charter, I would not understand=20
> why such proposal would not be accepted.

My guess is that would be in scope of an AAAext WG, but I am
unsure if it is in scope of a RADIUSext WG.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:52:45 +0000
content-class: urn:content-classes:message
Subject: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 20:51:25 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi,

> Is the scope of work going to remain the same?

My feeling is that the scope would basically be the sam.
=20
> If not, how do limited resources get mapped between RADIUS/Diameter?

I would have resources if RADIUS and Diameter compatibility is included.
I have less interest in pure RADIUS.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:33:18 +0000
Date: Wed, 31 Mar 2004 20:30:07 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: AAAEXT charter, Take 1

Hi Avi,

> Is the scope of work going to remain the same?

I think it is. See also my answer to Bernard
about that.

> If not, how do limited resources get mapped between RADIUS/Diameter?

I think there's two parts to the answer on this:

(1) Are there new, Diameter, applications that the group should
     take care of. I think not, see above.

(2) Are the RADIUS extensions going to be produced with or without
     concern for interoperability requirements? If with them, then
     we just need to find the resources. If without them, we still
     need to find the resources because the issue is going come back
     to us at IETF Last Call time, if not sooner...

> Will the combining of the WGs further delay RADIUS EXT WG.  If yes then I
> would vote for not combining the groups.  If however, the effect is to
> somehow accelerate the WG and work items then I would support this effort.

I think AAA WG is going to be closed down when it finishes its
work. I.e. this would not be a merge with anything, just focusing
the work in RADEXT so that, for instance, NAI or LAN attribute
work doesn't get RADIUS-only.

Hope this helps,

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:24:11 +0000
Date: Wed, 31 Mar 2004 20:21:12 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: MORAND Lionel FTRD/DAC/ISS <[email-masked]>
Cc: Radius Extensions <[email-masked]>
Subject: Re: RE : AAAEXT charter, Take 1

MORAND Lionel FTRD/DAC/ISS wrote:
> Hi,
> 
> There is something unclear in the Jari's proposal. The first part of the charter states that Diameter AND RADIUS extensions will be investigated. The rest of the text is based on the previous proposal in which only RADIUS extensions were considered as well as Diameter/Radius compatibility.

Ok. Let me try to clarify. Hope this helps:

Here's the list of proposed work items. I have
marked the general ones with "GEN", RADIUS-only
ones with "RAD", and RADIUS extensions with some
kind of compatibility need for Diameter with "RAD-COMPAT".

- RADIUS design guidelines [RAD]
- RADIUS/Diameter translation [GEN -- though perhaps best
   treated per application]
- Revised NAI specification [GEN]
- Pre-paid support [RAD-COMPAT]
- SIP support [RAD-COMPAT]
- LAN attributes [GEN]
- MIB update [RAD]

So thats a total of seven work items, three out of
which are generic, two are pure RADIUS, and two are
RADIUS with some compatibility requirements for
Diameter.

> If there is a proposal for enhancing the current NASREQ application for LAN/WLAN (with a new command or new madatory AVP for instance), would it be now considered as possible work item? I know that the goal is to narrow as much as possible the scope of this working group on RADIUS extensions but reading the first part of charter, I would not understand why such proposal would not be accepted.

There is a proposal for adding better support for LANs and WLANs,
see Farid Adrangi's draft. Its been written for RADIUS only, though
it should presumably work through the usual Diameter NASREQ
translation. Certainly the final RFC, when we get there, should
ensure this. I'd hope that we don't need to duplicate the work
for Diameter NASREQ, and one document would be sufficient. It
certainly seems so at this moment.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:14:53 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 12:13:59 -0500

Questions:

Is the scope of work going to remain the same?

If not, how do limited resources get mapped between RADIUS/Diameter?

Concerns:

Will the combining of the WGs further delay RADIUS EXT WG.  If yes then I
would vote for not combining the groups.  If however, the effect is to
somehow accelerate the WG and work items then I would support this effort.

Avi

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, March 31, 2004 10:52 AM
> To: [email-masked]
> Subject: RE: AAAEXT charter, Take 1
> 
> 
> > For what its worth, I agree with Jari's suggested modified 
> charter. I 
> > have more interest in the converged view of supporting both 
> RADIUS & 
> > Diameter, so I'm motivated by Jari's charter to be involved.
> 
> How do other participants feel about a "AAAEXT" charter?
> Should we rename the potential WG and re-orient towards 
> handling both RADIUS and Diameter in a single WG?
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 17:02:52 +0000
content-class: urn:content-classes:message
Subject: RE : AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 19:01:41 +0200
From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
To: <[email-masked]>, "Richard Perlman" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: "Radius Extensions" <[email-masked]>

Hi,

There is something unclear in the Jari's proposal. The first part of the =
charter states that Diameter AND RADIUS extensions will be investigated. =
The rest of the text is based on the previous proposal in which only =
RADIUS extensions were considered as well as Diameter/Radius =
compatibility.

If there is a proposal for enhancing the current NASREQ application for =
LAN/WLAN (with a new command or new madatory AVP for instance), would it =
be now considered as possible work item? I know that the goal is to =
narrow as much as possible the scope of this working group on RADIUS =
extensions but reading the first part of charter, I would not understand =
why such proposal would not be accepted.

Lionel

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de Jari Arkko
> Envoy=E9 : mercredi 31 mars 2004 18:37
> =C0 : Richard Perlman; Bernard Aboba
> Cc : Radius Extensions
> Objet : Re: AAAEXT charter, Take 1
>=20
>=20
> Bernard wrote:
>=20
> > Should we rename the potential WG and re-orient towards=20
> handling both=20
> > RADIUS and Diameter in a single WG?
>=20
> Note that I'm not sure how much "re-orient" we need.
> What I suggested did not really change the list of
> work items. I basically just requested the fact of
> common impact be recognized, in terms of components
> that are not specific to RADIUS as well as translation=20
> requirements. The common portion is IMHO large enough to=20
> warrant a change in the name as well.
>=20
> It may be fair to ask whether, as a part of this re-orient",=20
> the group should start doing possibly OTHER extensions than=20
> those currently listed. It didn't mean to imply this. I think=20
> the current charter is reasonable and it isn't easy to=20
> increase the number of work items a lot, whether or not my=20
> suggestion is adopted.
>=20
> So, work beyond the currently discussed items probably
> has to go to another place (such as the application WG)
> in any case, or wait until most of RADEXT/AAAEXT items
> have been completed.
>=20
> > Personally, I'd like to keep the work separate.  There is certainly=20
> > good reason for the work on DIAMETER and RADIUS futures to=20
> coordinate=20
> > with each other, but I think the actual WGs should be separate.
> >=20
> > One good reason is to avoid endless battles over whether a certain=20
> > extension should be in D, R or both.  Let each group work=20
> out the best=20
> > path, that is consistent with overall IETF/IESG direction.
>=20
> I believe the charter is pretty clear already about which=20
> extensions are to be done, and on which protocol. I think=20
> that's good. Is there a specific extension that you worry about?
>=20
> However, I think it would be very unfortunate if we
> started divergent standardization for, say, RADIUS NAIs
> and Diameter NAIs, or created a WLAN attribute set for
> RADIUS that couldn't be converted to Diameter using NASREQ,
> or if the WLAN attributes for Diameter and RADIUS contained=20
> different information.
>=20
> --Jari
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 16:45:26 +0000
From: Greg Weber <[email-masked]>
Subject: Re: AAAEXT charter, Take 1
To: [email-masked] (Bernard Aboba)
Date: Wed, 31 Mar 2004 11:43:53 -0500 (EST)
Cc: [email-masked]

> 
> > For what its worth, I agree with Jari's suggested modified charter.
> > I have more interest in the converged view of supporting both RADIUS
> > & Diameter, so I'm motivated by Jari's charter to be involved.
> 
> How do other participants feel about a "AAAEXT" charter?
> Should we rename the potential WG and re-orient towards handling both
> RADIUS and Diameter in a single WG?

I would support this.  We're talking about the same problem
spaces and the same interested parties.  Separating these into
disparate WGs seems wasteful from a resource point of view.
Separation would also likely tax interoperability.  Isn't this
a situation akin to IKE & IKEv2: not totally compatible but
addressed via the same WG.

Greg

> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 16:40:19 +0000
Date: Wed, 31 Mar 2004 19:37:04 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Richard Perlman <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: Radius Extensions <[email-masked]>
Subject: Re: AAAEXT charter, Take 1

Bernard wrote:

> Should we rename the potential WG and re-orient towards handling both
> RADIUS and Diameter in a single WG?

Note that I'm not sure how much "re-orient" we need.
What I suggested did not really change the list of
work items. I basically just requested the fact of
common impact be recognized, in terms of components
that are not specific to RADIUS as well as translation
requirements. The common portion is IMHO large enough
to warrant a change in the name as well.

It may be fair to ask whether, as a part of this re-orient",
the group should start doing possibly OTHER extensions
than those currently listed. It didn't mean to imply
this. I think the current charter is reasonable and
it isn't easy to increase the number of work items a
lot, whether or not my suggestion is adopted.

So, work beyond the currently discussed items probably
has to go to another place (such as the application WG)
in any case, or wait until most of RADEXT/AAAEXT items
have been completed.

> Personally, I'd like to keep the work separate.  There is certainly good
> reason for the work on DIAMETER and RADIUS futures to coordinate with each
> other, but I think the actual WGs should be separate.
> 
> One good reason is to avoid endless battles over whether a certain extension
> should be in D, R or both.  Let each group work out the best path, that is
> consistent with overall IETF/IESG direction.

I believe the charter is pretty clear already about which
extensions are to be done, and on which protocol. I think
that's good. Is there a specific extension that you worry
about?

However, I think it would be very unfortunate if we
started divergent standardization for, say, RADIUS NAIs
and Diameter NAIs, or created a WLAN attribute set for
RADIUS that couldn't be converted to Diameter using NASREQ,
or if the WLAN attributes for Diameter and RADIUS contained
different information.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 16:23:04 +0000
content-class: urn:content-classes:message
Subject: RE: AAAEXT charter, Take 1
Date: Wed, 31 Mar 2004 19:14:21 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Richard,

> Personally, I'd like to keep the work separate.  There is certainly =
good
> reason for the work on DIAMETER and RADIUS futures to coordinate with =
each
> other, but I think the actual WGs should be separate.
>=20
> One good reason is to avoid endless battles over whether a certain =
extension
> should be in D, R or both.  Let each group work out the best path, =
that is
> consistent with overall IETF/IESG direction.

There is no Diameter WG.  The current AAA WG is shutting down.  I think
what we are talking about is not debating where extensions belong, but
how to manage interworking between RADIUS & Diameter.  One example would
be the WLAN extentions.  It would make sense that RADIUS WLAN extensions
interworking with Diameter servers, for example.  Additionally, things
like the NAI update document is not specific to RADIUS or Diameter, but
is a common AAA topic.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 15:58:58 +0000
Date: Wed, 31 Mar 2004 07:58:33 -0800
Subject: Re: AAAEXT charter, Take 1
From: Richard Perlman <[email-masked]>
To: Bernard Aboba <[email-masked]>, Radius Extensions <[email-masked]>

Bernard:

Personally, I'd like to keep the work separate.  There is certainly good
reason for the work on DIAMETER and RADIUS futures to coordinate with each
other, but I think the actual WGs should be separate.

One good reason is to avoid endless battles over whether a certain extension
should be in D, R or both.  Let each group work out the best path, that is
consistent with overall IETF/IESG direction.

Richard

On 3/31/04 07:51, "Bernard Aboba" <[email-masked]> wrote:

>> For what its worth, I agree with Jari's suggested modified charter.
>> I have more interest in the converged view of supporting both RADIUS
>> & Diameter, so I'm motivated by Jari's charter to be involved.
> 
> How do other participants feel about a "AAAEXT" charter?
> Should we rename the potential WG and re-orient towards handling both
> RADIUS and Diameter in a single WG?
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 15:44:49 +0000
Date: Wed, 31 Mar 2004 07:51:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RE: AAAEXT charter, Take 1

> For what its worth, I agree with Jari's suggested modified charter.
> I have more interest in the converged view of supporting both RADIUS
> & Diameter, so I'm motivated by Jari's charter to be involved.

How do other participants feel about a "AAAEXT" charter?
Should we rename the potential WG and re-orient towards handling both
RADIUS and Diameter in a single WG?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 31 Mar 2004 05:33:55 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8
Date: Wed, 31 Mar 2004 08:31:24 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

> Based on the above comments, I'd like to suggest the
> following text as the charter:

For what its worth, I agree with Jari's suggested modified charter.
I have more interest in the converged view of supporting both RADIUS
& Diameter, so I'm motivated by Jari's charter to be involved.

John

> AAA Extensions Working Group (AAAEXT) Charter
> Last Modified: 2004-03-24
>=20
> Chair(s):
> David Nelson <[email-masked]>
>=20
> Operations and Management Area Director(s):
> David Kessens <[email-masked]>
> Bert Wijnen <[email-masked]>
>=20
> Operations and Management Area Advisor:
> David Kessens <[email-masked]>
>=20
> Technical Advisor:
> Paul Congdon <[email-masked]>
>=20
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
>=20
> Description of Working Group:
>=20
> The AAA Extensions Working Group will focus on maintaining
> AAA related specifications, adding support for the use of
> AAA protocols (RADIUS, Diameter) for Local Area Network
> authentication, authorization, and accounting, and adding
> support to the RADIUS porocol for IP telephony and prepaid
> applications.
>=20
> In order to ensure backward compatibility with RADIUS as well as
> Diameter, the following restrictions are imposed on extensions
> considered by the WG:
>=20
> - All work MUST be backward compatible with existing RADIUS RFCs,
>    including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
>    and 3580.
>=20
> - All extensions consisting of carrying additional information
>    attributes MUST be defined in a manner suitable for the use
>    of the same attributes in both RADIUS and Diameter.
>=20
> - All other work MUST be compatible with equivalent facilities in
>    Diameter, if such facilities already exist. A Diameter Translation
>    Considerations section MUST be provided to describe the mapping
>    that a RADIUS-Diameter translation gateway would have to implement.
>=20
> - The RADIUS maximum packet size (4K) will not be increased.
>=20
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
>=20
> Work Items
>=20
> The immediate goals of the AAAEXT working group are to address the
> following issues:
>=20
> - RADIUS design guidelines.  This document will provide guidelines
>    for design of RADIUS attributes, including discussion of the
>    appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
>    document will also review RADIUS data types and associated
>    backwards compatibility issues.
>=20
> - Revised NAI specification.  This document, known as "RFC 2486bis"
>    will revise the NAI specification to correct known errors,
>    provide more details on routing, add support for privacy,
>    as well as handling internationalization.
>=20
> - Pre-paid support.  Prepaid services are contemplated in a number
>    of potential applications, including wireless LAN access and IP
>    telephony.  In order to enable support of pre-paid services in an
>    interoperable way, the WG will provide definitions of the
>    attributes required to support operator service models for
>    pre-paid, as documented in liaison communications.  Support
>    will be included for time, volume, and event oriented charging
>    as well as support for limited differential charging.
>    This document will be compatible with Diameter Credit Control.
>=20
> - SIP support.  RADIUS is currently used for SIP authentication,
>    authorization and accounting.  Standardization of these attributes
>    will enable improved interoperability.
>=20
>    This document will be compatible with existing IETF RFCs
>    on HTTP Digest, including RFC 2617, 3261, and 3310.
>=20
>    This document will be compatible with Diameter SIP application,
>    but not necessarily vice versa, as the Diameter SIP application
>    supports additional functionality such as routing.
>=20
> - LAN attributes.  New attributes have been proposed to enable use of
>    authentication, authorization and accounting in wired and=20
> wireless LANs.
>    Standardization of these attributes will enable improved
>    interoperability. These attributes are defined in a manner where
>    their use in both RADIUS and Diameter is possible through the
>    same document.
>=20
> - MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
>    changes are required to address this issue.
>=20
> Goals and Milestones:
>=20
> Dec 04  Updated RADIUS MIBs submitted for publication.
> Dec 04  SIP authentication draft submitted as a Proposed Standard RFC.
> Dec 04  RFC 2486bis submitted as a Proposed Standard.
> Feb 05  WLAN attributes submitted as a Proposed Standard RFC.
> Dec 05  RADIUS design guidelines submitted as an Informational RFC.
> Dec 05  LAN attributes submitted as a Proposed Standard RFC.
> Dec 05  Prepaid draft submitted as a Proposed Standard RFC.
>=20
> Quality Control Plan
>=20
> In order to ensure quality of work:
>=20
> * This WG will not be chartered until sufficient resources can be
>    demonstrated to be available to guarantee a high probability of
>    success.  This includes recruitment of a core of editors and
>    reviewers with significant IETF experience and demonstrated time
>    commitment.
>=20
> * All drafts will need to undergo review prior to acceptance=20
> as WG work
>    items, which includes demonstration that the drafts are backward
>    compatible with RADIUS RFCs and are compatible with equivalent
>    facilities in Diameter.  Given the backwards compatibility=20
> issues, no
>    document including sub-attributes will be considered for=20
> publication as
>    an RFC before the RADIUS design guidelines and RADIUS/Diameter
>    translation work items are completed, analyzing the issues in
>    a comprehensive way.
>=20
> * The WG will utilize an automated issue tracking system.
>=20
> * XML to RFC will be used in production of documents.  This enables
>    production of HTML and text files from a single source file as
>    well as automated production of difference files.
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 26 Mar 2004 21:00:28 +0000
Content-class: urn:content-classes:message
Subject: RE: SPAM: AW: structured string attributes,  RADEXT charter, Take 8
Date: Fri, 26 Mar 2004 15:59:59 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Wolfgang Back writes...

> No. My position is that there are attributes that don't make sense if
they
> are used alone.
>=20
> For example, User-Name can be used with or without User-Password.
> So, User-Name and User-Password are separate attributes.
>=20
> On the other hand CHAP ident and CHAP response only make sense if they
are
> used together. So somebody grouped them into a single attribute. The
same
> applies for the HTTP digest extension.

Sorry for the delay in replying.  Our e-mail system had for some reason
labeled this post as SPAM.  (??)

OK.  I'm beginning to understand.  Maybe this is a terminology issue,
because I would not have considered the two parts of a CHAP response,
the ID, and the Hash, as separate "attributes" grouped together for
convenience.  When are two attributes independent?  I guess a
clarification would help, and we could certainly add that to the RADIUS
design guidelines document.  =20

> The last draft charter says, that anybody proposing structured string
> attributes must show that this does not break existing RfC-compliant
> implementations.

The desire is to avoid the "special case" situations, such as the CHAP
case, whenever possible.  Some of the proposals I've seen have
multipart, or "grouped" attributes, where the inter-part binding is not
as mandatory as the binding in the CHAP example.

> I think we are both - for different reasons - not very happy about it.
> This is one definition of a compromise.

Yes, it is.  :-)

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 20:17:23 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8 ---  The Prepaid Attributes
Date: Thu, 25 Mar 2004 15:17:11 -0500

Bernard writes:

> perhaps we can examine 
> the proposals to see how they compare to established usage. 

Here are my attributes.  There are two of them. All of type string 
encoded using TLVs.

5.1 PPAC Attribute 
    
   The PrepaidAccountingCapability (PPAC) attribute is sent in the 
   Access-Request message by a Prepaid Capable NAS and is used to 
   describe the PrePaid capabilities of the NAS.  The PPAC is available 
   to be sent in an Access-Accept message by the Prepaid server to 
   indicate the type of prepaid metering that is to be applied to this 
   session.   
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | TYPE          | LENGTH        | SUB-TYPE 1    | LENGTH        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    AvailableInClient (AiC)                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 2    | LENGTH        |   SelectedForSession (SFS)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               |                                 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 

   TYPE  : value of PPAC 
  
   LENGTH: 14 
   VALUE : String 
    
   The value MUST be encoded as follows: 
    
   Sub-Type (=1)          : Sub-Type for AvailableInClient attribute  
   Length                 : Length of AvailableInClient attribute  
                            (= 6 octets)  
   AvailableInClient (AiC): 
     
   The optional AvailableInClient Sub-Type, generated by the PrePaid 
   client, indicates the PrePaid Accounting capabilities of the NAS and 
   shall be bitmap encoded. The possible values are:  
     
      0x00000001  PrePaid Accounting for Volume supported  
      0x00000010  PrePaid Accounting for Duration supported  
      0x00000011  PrePaid Accounting for Volume and Duration supported 
                  (non concurrently)  
      Others      Reserved, treat like Not Capable of PrePaid 
                  Accounting (=0).  
    
   Sub-Type (=2)          : Sub-Type for SelectedForSession attribute  
   Length                 : Length of SelectedForSession attribute  
                            (= 6 octets)  
   SelectedForSession (SfS): 
     
   The optional SelectedForSession Sub-Type, generated by the PrePaid 
   server, indicates the PrePaid Accounting capability to be used for a 
   given session. The possible values are: 
     
      0x00000000  PrePaid Accounting not used  
      0x00000001  Usage of PrePaid Accounting for Volume.  
                  (only possible if the AvailableInClient supports 
                  PrePaid Accounting for Volume)  
      0x00000010  Usage of PrePaid Accounting for Duration.  
                  (only possible if the AvailableInClient supports 
                  PrePaid Accounting for Duration)  
      0x00000011  Usage of PrePaid Accounting for Volume and Duration 
                  (non concurrent) (only possible if the 
                  AvailableInClient supports PrePaid Accounting for 
                  Volume and duration)  
      Others      Reserved, treat like PrePaid Accounting not used(=0).  
    
5.3 PPAQ Attribute 
    
   The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and 
   Access-Accept messages.  In Authorize Only Access-Request messages 
   it is used to report usage and request further quota; in an Access-
   Accept message it is used to allocate the quota (initial quota and 
   subsequent quotas). 
    
   The attribute consists of a number of subtypes.  Subtypes not used 
   are omitted in the message. 

   0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | TYPE          | LENGTH        | SUB-TYPE 1    | LENGTH        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        QuotaIdentifier (QID)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 2    | LENGTH        |        Volume Quota           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Volume Quota               | SUB-TYPE 3    | LENGTH        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
   |  VolumeQuotaOverflow (VQO)    | SUB-TYPE 4    | LENGTH        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        VolumeThreshold (VT)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 5    | LENGTH        | VolumeThresholdOverflow (VTO) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 6    | LENGTH        |      DurationQuota (DQ)       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    DurationQuota (DQ)         | SUB-TYPE 7    | LENGTH        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      DurationThreshold (DT)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 8    | LENGTH        | Update-Reason attribute (UR)  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SUB-TYPE 9    | LENGTH        | PrePaidServer                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |            PrePaidServer                                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type  : Value of PPAQ 
   Length: variable, greater than 8 
    
   String:  The String value MUST be encoded as follows: 
    
   Sub-Type (=1):  Sub-Type for QuotaIDentifier attribute 
   Length       :  Length of QuotaIDentifier attribute (= 6 octets) 
    
   QuotaIDentifier (QID): 
    
      The QuotaIDentifier Sub-Type is generated by the PrePaid server 
      at allocation of a Volume and/or Duration Quota. The on-line 
  
      quota update RADIUS Access-Request message sent from the Access 
      Device to the PPS shall include a previously received 
      QuotaIDentifier.  
    
   Sub-Type (=2): Sub-Type for VolumeQuota attribute 
   Length       : length of VolumeQuota attribute (= 6 octets) 
    
   VolumeQuota (VQ):  
    
      The optional VolumeQuota Sub-Type is only present if Volume Based 
      charging is used. In RADIUS Access-Accept message (PPS to Access 
      Device direction), it indicates the Volume (in octets) allocated 
      for the session by the PrePaid server. In RADIUS Authorize Only 
      Access-Request message (Access Device to PPS direction), it 
      indicates the total used volume (in octets) for both forward and 
      reverse traffic applicable to PrePaid accounting. 
    
   Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 
   Length       : length of VolumeQuotaOverflow attribute (= 4 octets) 
    
   VolumeQuotaOverflow (VQO): 
    
      The optional VolumeQuotaOverflow Sub-Type is used to indicate how 
      many times the VolumeQuota counter has wrapped around 2^32 over 
      the course of the service being provided. 
    
   Sub-Type (=4): Sub-Type for VolumeThreshold attribute  
   Length       : length of VolumeThreshold attribute (= 6 octets) 
    
   VolumeThreshold (VT): 
    
      The VolumeThreshold Sub-Type shall always be present if 
      VolumeQuota is present in a RADIUS Access-Accept message (PPS to 
      Access Device direction). It is generated by the PrePaid server 
      and indicates the volume (in octets) that shall be used before 
      requesting quota update. This threshold should not be larger than 
      the VolumeQuota.  
    
   Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 
   Length       : Length of VolumeThresholdOverflow attribute  
                   (= 4 octets) 
    
   VolumeThresholdOverflow (VTO): 
    
      The optional VolumeThresholdOverflow Sub-Type is used to indicate 
      how many times the VolumeThreshold counter has wrapped around 
      2^32 over the course of the service being provided. 
    
   Sub-Type (=6): Sub-Type for DurationQuota attribute  
   Length       : length of DurationQuota attribute (= 6 octets) 
    
   DurationQuota (DQ): 
    
      The optional DurationQuota Sub-Type is only present if Duration 
      Based charging is used. In RADIUS Access-Accept message (PPS to 
      Access Device direction), it indicates the Duration (in seconds) 
      allocated for the session by the PrePaid server. In on-line 
      RADIUS Access-Accept message (PPC to PPS direction), it indicates 
      the total Duration (in seconds) since the start of the accounting 
      session related to the QuotaID.  
     
   Sub-Type (=7): Sub-Type for DurationThreshold attribute 
   Length       : length of DurationThreshold attribute (= 6 octets) 
    
   DurationThreshold (DT):  
    
      The DurationThreshold Sub-Type shall always be present if 
      DurationQuota is present in a RADIUS Access-Accept message (PPS 
      to Access Device direction). It represents the duration (in 
      seconds) that shall be used by the session before requesting 
      quota update. This threshold should not be larger than the 
      DurationQuota and shall always be sent with the DurationQuota.  
    
   Sub-Type (=8): Sub-Type for Update-Reason attribute 
   Length       : length of Update-Reason attribute (= 4 octets) 
    
   Update-Reason attribute (UR):  
       
      The Update-Reason Sub-Type shall be present in the on-line RADIUS 
      Access-Request message (Access Device to PPS direction). It 
      indicates the reason for initiating the on-line quota update 
      operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 
      associated resources are released at the client side, and 
      therefore the PPS shall not allocate a new quota in the RADIUS 
      Access_Accept message.  

      1. Pre-initialization 
      2. Initial request 
      3. Threshold reached 
      4. Quota reached 
      5. Remote Forced disconnect 
      6. Client Service termination 
      7. Main SI released 
      8. Service Instance not established 
       
   Sub-Type (=9) : Sub-Type for PrePaidServer attribute 
   Length        : Length of PrePaidServer  
                   (IPv4 = 6 octets, IPv6= 18 octets 
    
   PrePaidServer: 
    
      The optional, multi-value PrePaidServer indicates the address of 
      the serving PrePaid System. If present, the Home RADIUS server 
      uses this address to route the message to the serving PrePaid 
      Server. The attribute may be sent by the Home RADIUS server. If 
      present in the incoming RADIUS Access-Accept message, the PDSN 
      shall send this attribute back without modifying it in the 
      subsequent RADIUS Access-Request message, except for the first 
      one. If multiple values are present, the PDSN shall not change 
      the order of the attributes. 
    
   NOTES: 
    
   Either Volume-Quota or Time-Quota MUST appear in the attribute. 
   Volume Threshold may only appear if Volume Quota appears 
   If the Access Device can measure time, and if Time-Threshold appears 
   with Volume Quota, then the Access device should trigger a quota 
   replenishment when the Current Time >= Time-Threshold. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2004 3:04 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: RADEXT charter, Take 8 
> 
> 
> Maybe it will help a bit to look at the definitions of each 
> of the attributes you've cited.  From what I can tell, there 
> are quite a few examples of complex "String" fields sent from 
> RADIUS server to NAS.  In some cases, these fields are 
> calculated on the fly, requiring a RADIUS server code change 
> (e.g. Tunnel Password) but in other cases, the field could be 
> entered statically by an admin with the patience to do so.
> 
> There are also examples of complex "String" fields sent from 
> NAS to RADIUS server, which require the RADIUS server to 
> parse them (e.g. CHAP-PASSWORD, ARAP-PASSWORD).
> 
> And there is an example of "Grouped AVPs" (e.g. Vendor-Specific).
> 
> Based on what has been done before, perhaps we can examine 
> the proposals to see how they compare to established usage.  
> In this discussion, I think it would be helpful to avoid use 
> of the term "sub-attribute" or "sub-type" since this seems to 
> be used to refer to a variety of quite different things -- 
> from "Grouped AVPs" to "complex strings".  As a result, I 
> think we may be suffering from some terminology confusion.
> 
> 
> > User-Name
> 
> This is defined in Section 5.1 of RFC 2865 as follows:
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> So this is just an element of type "String".  Proxies
> do parse (and even edit) this attribute.
> 
> > Chap-Password  IDENT + PASSWORD
> 
> This is defined in Section 5.3 of RFC 2865 as follows:
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  CHAP Ident   |  String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> So here we have a one octet identifier followed by a 
> "String".  RADIUS servers do need to parse this in order to 
> validate the password.
> 
> > Framed-Route   A list of IP-Addresses.
> 
> This is defined in Section 5.22 of RFC 2865 as follows:
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  Text ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> Where "Text" is defined this way:
> 
>       The Text field is one or more octets, and its contents are
>       implementation dependent.  It is intended to be human 
> readable and
>       MUST NOT affect operation of the protocol.  It is 
> recommended that
>       the message contain UTF-8 encoded 10646 [7] characters.
> 
>       For IP routes, it SHOULD contain a destination prefix in dotted
>       quad form optionally followed by a slash and a decimal length
>       specifier stating how many high order bits of the prefix to use.
> 
> Here the admin enters the string and it is sent to the NAS 
> where it is parsed.
> 
> > Vendor-Specific allows more then one attribute.
> 
> Section 5.26 of RFC 2865 says the following:
> 
>      The String field is one or more octets.  The actual format of the
>       information is site or application specific, and a robust
>       implementation SHOULD support the field as 
> undistinguished octets.
> 
>       The codification of the range of allowed usage of this field is
>       outside the scope of this specification.
> 
>       It SHOULD be encoded as a sequence of vendor type / 
> vendor length
>       / value fields, as follows.  The Attribute-Specific field is
>       dependent on the vendor's definition of that attribute.  An
>       example encoding of the Vendor-Specific attribute using this
>       method follows:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Vendor type   | 
> Vendor length |
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>       Multiple subattributes MAY be encoded within a single Vendor-
>       Specific attribute, although they do not have to be.
> 
> Here there is parsing on the RADIUS server side.
> 
> > Tunnel-Password  Salt plus password
> 
> This is defined in Section 3.5 of RFC 2868:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |     Tag       |   Salt
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       Salt (cont)  |   String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Here the RADIUS server needs to choose the salt and then 
> calculate the "String" portion appropriately, then send this 
> to the NAS.
> 
> > ARAP-Password  Multiple values
> 
> This is defined in Section 5.4 of RFC 2869:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |             Value1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    |             Value2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    |             Value3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    |             Value4
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Looks like parsing is required on the RADIUS server for this 
> one, though I'm no ARAP expert.
> 
> > ARAP-Features  Again multiple-values
> 
> This is defined in Section 5.5 of RFC 2869:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |     Value1    |    Value2     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Value3                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Value4                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Value5                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Ditto.
> 
> > Connect-Info   a bunch of attributes.
> 
> This is defined in Section 5.11 of RFC 2869:
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |     Text...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where "Text" is defined as follows:
> 
>       The Text field consists of UTF-8 encoded 10646 [8] characters.
>       The connection speed SHOULD be included at the beginning of the
>       first Connect-Info attribute in the packet.  If the transmit and
>       receive connection speeds differ, they may both be 
> included in the
>       first attribute with the transmit speed first (the speed the NAS
>       modem transmits at), a slash (/), the receive speed, then
>       optionally other information.
> 
>       For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
> 
>       More than one Connect-Info attribute may be present in an
>       Accounting-Request packet to accommodate expected efforts by ITU
>       to have modems report more connection information in a standard
>       format that might exceed 252 octets.
> 
> So here, the NAS sends a String to the RADIUS server which 
> typically just stores it.
> 
> > Framed-IPv6-Prefix  Prefix-Length and Pre-fix
> 
> This is defined in Section 2.3 of RFC 3162:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |  Reserved     | Prefix-Length |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                 Prefix
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                 Prefix
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                 Prefix
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                 Prefix                             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> This can be stored as a string on the RADIUS server and sent 
> to the NAS, which parses it.
> 
> > Framed-IPv6-Route   a list of ip addresses
> 
> This is defined in Section 2.5 of RFC 3162:
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  Text ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> Where "Text" is defined as:
> 
>       The Text field is one or more octets, and its contents are
>       implementation dependent.  The field is not NUL (hex 00)
>       terminated.  It is intended to be human readable and MUST NOT
>       affect operation of the protocol.
> 
>       For IPv6 routes, it SHOULD contain a destination prefix 
> optionally
>       followed by a slash and a decimal length specifier stating how
>       many high order bits of the prefix to use.  That is 
> followed by a
>       space, a gateway address, a space, and one or more metrics
>       (encoded in decimal) separated by spaces.  Prefixes and 
> addresses
>       are formatted as described in [16].  For example,
>       "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 19:55:43 +0000
Date: Thu, 25 Mar 2004 12:03:47 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: RADEXT charter, Take 8 

Maybe it will help a bit to look at the definitions of each of the
attributes you've cited.  From what I can tell, there are quite a few
examples of complex "String" fields sent from RADIUS server to NAS.  In
some cases, these fields are calculated on the fly, requiring a RADIUS
server code change (e.g. Tunnel Password) but in other cases, the field
could be entered statically by an admin with the patience to do so.

There are also examples of complex "String" fields sent from NAS to RADIUS
server, which require the RADIUS server to parse them (e.g. CHAP-PASSWORD,
ARAP-PASSWORD).

And there is an example of "Grouped AVPs" (e.g. Vendor-Specific).

Based on what has been done before, perhaps we can examine the proposals
to see how they compare to established usage.  In this
discussion, I think it would be helpful to avoid use of the term
"sub-attribute" or "sub-type" since this seems to be used to refer to a
variety of quite different things -- from "Grouped AVPs" to "complex
strings".  As a result, I think we may be suffering from some terminology
confusion.

> User-Name

This is defined in Section 5.1 of RFC 2865 as follows:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

So this is just an element of type "String".  Proxies
do parse (and even edit) this attribute.

> Chap-Password  IDENT + PASSWORD

This is defined in Section 5.3 of RFC 2865 as follows:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  CHAP Ident   |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

So here we have a one octet identifier followed by a "String".  RADIUS
servers do need to parse this in order to validate the password.

> Framed-Route   A list of IP-Addresses.

This is defined in Section 5.22 of RFC 2865 as follows:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Where "Text" is defined this way:

      The Text field is one or more octets, and its contents are
      implementation dependent.  It is intended to be human readable and
      MUST NOT affect operation of the protocol.  It is recommended that
      the message contain UTF-8 encoded 10646 [7] characters.

      For IP routes, it SHOULD contain a destination prefix in dotted
      quad form optionally followed by a slash and a decimal length
      specifier stating how many high order bits of the prefix to use.

Here the admin enters the string and it is sent to the NAS where it is
parsed.

> Vendor-Specific allows more then one attribute.

Section 5.26 of RFC 2865 says the following:

     The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Here there is parsing on the RADIUS server side.

> Tunnel-Password  Salt plus password

This is defined in Section 3.5 of RFC 2868:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here the RADIUS server needs to choose the salt and then calculate the
"String" portion appropriately, then send this to the NAS.

> ARAP-Password  Multiple values

This is defined in Section 5.4 of RFC 2869:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Looks like parsing is required on the RADIUS server for this one, though
I'm no ARAP expert.

> ARAP-Features  Again multiple-values

This is defined in Section 5.5 of RFC 2869:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Value1    |    Value2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value3                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value4                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value5                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ditto.

> Connect-Info   a bunch of attributes.

This is defined in Section 5.11 of RFC 2869:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Text...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where "Text" is defined as follows:

      The Text field consists of UTF-8 encoded 10646 [8] characters.
      The connection speed SHOULD be included at the beginning of the
      first Connect-Info attribute in the packet.  If the transmit and
      receive connection speeds differ, they may both be included in the
      first attribute with the transmit speed first (the speed the NAS
      modem transmits at), a slash (/), the receive speed, then
      optionally other information.

      For example, "28800 V42BIS/LAPM" or "52000/31200 V90"

      More than one Connect-Info attribute may be present in an
      Accounting-Request packet to accommodate expected efforts by ITU
      to have modems report more connection information in a standard
      format that might exceed 252 octets.

So here, the NAS sends a String to the RADIUS server which typically just
stores it.

> Framed-IPv6-Prefix  Prefix-Length and Pre-fix

This is defined in Section 2.3 of RFC 3162:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Reserved     | Prefix-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This can be stored as a string on the RADIUS server and sent to the NAS,
which parses it.

> Framed-IPv6-Route   a list of ip addresses

This is defined in Section 2.5 of RFC 3162:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Where "Text" is defined as:

      The Text field is one or more octets, and its contents are
      implementation dependent.  The field is not NUL (hex 00)
      terminated.  It is intended to be human readable and MUST NOT
      affect operation of the protocol.

      For IPv6 routes, it SHOULD contain a destination prefix optionally
      followed by a slash and a decimal length specifier stating how
      many high order bits of the prefix to use.  That is followed by a
      space, a gateway address, a space, and one or more metrics
      (encoded in decimal) separated by spaces.  Prefixes and addresses
      are formatted as described in [16].  For example,
      "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 19:48:05 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8 
Date: Thu, 25 Mar 2004 14:47:34 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Specifically looking at ARAP-Password and the attributes=20
> in Sterman or Prepaid
=A0
> All these uses seem to gather related information together.
=A0
> The only difference is the way the encoded the various=20
> Sub-Attributes that they contain.  ARAP uses fixed length=20
> encoding, while Prepaid and Sterman use TLV encoding.

OK. Since both Avi and Parviz have suggested the ARAP attributes as a =
basis for analysis, let's go with that.  I'll find some time in the next =
day or two to reply with my analysis.

-- Dave
=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 19:44:18 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8; dictionaries
Date: Thu, 25 Mar 2004 14:43:21 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Wolfgang Beck writes...

> (a) is more a matter of style. String attributes may only be
structured if
> the components cannot be used individually. We may need some more
> guidelines here.

Yes, and such guidelines are already a proposed WG deliverable.

> The definition of "break" can only be derived from the RADIUS RfCs. No
> WG could ever judge if an extension would work with every
implementation
> out there.

That's why IETF Standards Track protocols require multiple independent
implementations, protocol "plug-fests" and implementation reports before
they can advance along the standards track.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 19:24:36 +0000
To: [email-masked]
Subject: Re: RADEXT charter, Take 8; dictionaries
Date: Thu, 25 Mar 2004 20:23:41 +0100
From: [email-masked] (Wolfgang Beck)

David Nelson wrote:
> Hmmm...  I guess if the evidence presented to date does not convince
> you, then it entirely possible that you will never be convinced.  Maybe
> it has to do with how one defines "break".  I define it as (a) deviation
> from the established protocol model, and (b) requiring changes to the
> protocol parsing engine of RADIUS implementations (as opposed the
> changes in the semantics enforcement engine, which is obviously required
> each time a new data element is introduced).

The problem with (b) is, that implementation details - like the concept
of a dictionary - are not standardized. You are saying that changes to the
attribute parser are painful and this might be true for some
implementations. In other implementations, parser extensions are the
easy part and changing the semantic enforcement engine is hard.

(a) is more a matter of style. String attributes may only be structured if
the components cannot be used individually. We may need some more
guidelines here.

The definition of "break" can only be derived from the RADIUS RfCs. No
WG could ever judge if an extension would work with every implementation
out there.

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 17:58:06 +0000
Date: Thu, 25 Mar 2004 10:06:16 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of RFC 2486bis

Abstract

The original RFC 2486 contained the following text:

"In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users.  This document proposes syntax for the Network
Access Identifier (NAI), the userID submitted by the client during
PPP authentication. It is expected that this will be of interest for
support of roaming as well as tunneling."

In RFC 2486bis, this was changed to:

"In order to provide roaming services, it is necessary to have a
standardized method for identifying users.  This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during, for instance,  PPP and wireless LAN
authentication.

This paragraph appears to deprecate use of the NAI in tunneling
services as well as to generalize the use of the NAI beyond network
access.  Recommend changing to:

"In order to provide roaming services, it is necessary to have a
standardized method for identifying users.  This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during network authentication."

Section 1 says:

"   Considerable interest exists for a set of features that fit within
   the general category of "roaming capability" for dialup Internet
   users, wireless LAN authentication, and other applications."

Propose changing to:

"   Considerable interest exists for a set of features that fit within
   the general category of "roaming capability" for network access,
   including dialup Internet users, VPN usage, wireless LAN
   authentication, and other applications."

In Section 1.1, change:

"The Network Access Identifier (NAI) is the userID submitted by the
client during PPP authentication.  In roaming, the purpose of the
NAI is to identify the user as well as to assist in the routing of
the authentication request.  Please note that the NAI may not
necessarily be the same as the user's e-mail address or the userID
submitted in an application layer authentication.

   Network Access Server
             The Network Access Server (NAS) is the device that clients
             dial in order to get access to the network. In PPTP
             terminology this is referred to as the PPTP Access
             Concentrator (PAC), and in L2TP terminology, it is referred
             to as the L2TP Access Concentrator (LAC).
"

To:

"The Network Access Identifier (NAI) is the user identity submitted by the
client during network access authentication.  In roaming, the purpose of
the NAI is to identify the user as well as to assist in the routing of
the authentication request.  Please note that the NAI may not
necessarily be the same as the user's e-mail address or the user identity
submitted in an application layer authentication.

Network Access Server
The Network Access Server (NAS) is the device that clients
connect to in order to get access to the network. In PPTP
terminology this is referred to as the PPTP Access
Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it
is referred to as an Access Point."

Change "IPSEC tunnel mode" to "IPsec tunnel mode."

In Section 1.2, change:

"   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3]."

To:

"   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3]."

In Section 1.3, change:

"   As described in [8], there are a number of services implementing
   dialup roaming, and the number of Internet Service Providers involved
   in roaming consortia is increasing rapidly."

To:

"As described in [8], there are a number of providers offering
network access services, and the number of Internet Service Providers
involved in roaming consortia is increasing rapidly."

In Section 2.1, change:

"   c           = < a character as specified in
   Section 2.4
    >"

To:

"   c           = < a character as specified in Section 2.4 >"

Section 2.2 states:

"   Devices handling NAIs MUST support an NAI length of at least 253
   octets.  However, the following interoperability considerations
   should be noted:

   o  RFC 2486 required the support of NAIs only up to the length of 72
      octets.  As a result, it can generally not be assumed that all
      devices can support 253 octets.

   o  NAIs are often transported in the User-Name attribute of RADIUS
      [10].  Unfortunately, RADIUS requires devices to support content
      lengths of only 63 octets for this attribute.  As a result, it may
      not be possible to transfer NAIs beyond 63 octets through all
      devices.  In addition, due to its message structure, RADIUS is
      unable to support content lengths beyond 253 octets"

Effectively, this section admits that RFC 2486bis renders existing devices
non-compliant;  moreover, due to a variety of limitations it is not clear
that devices could be compliant even if they wanted to.  This seems
problematic.

It might make more sense to say:

"   Devices handling NAIs MUST support an NAI length of at least 72
   octets.  Support for an NAI length of 253 octets is RECOMMENDED.
   However, the following implementation issues should be considered:

   o  NAIs are often transported in the User-Name attribute of RADIUS
      [10].  Unfortunately, [RFC2865] Section 5.1 states that
      "the ability to handle at least 63 octets is recommended."
      As a result, it may not be possible to transfer NAIs
      beyond 63 octets through all devices.  In addition, since
      only a single User-Name attribute may be included in a RADIUS
      message and the maximum attribute length is 253 octets,
      RADIUS is unable to support NAI lengths beyond 253 octets."

Section 2.3 states:

"  Interpretation of the "username" part of the NAI depends on the realm
   in question.  Therefore, the "username" part SHOULD be treated as
   opaque data when processed by nodes that are not authoritative (in
   some sense) for that realm."

I am not sure what "authoritative for that realm" means here.  This is
DNS terminology.  Does it imply that the NAS or RADIUS server supports
dynamic DNS client udpate or is running a DNS server itself?

Section 2.4 says:

"
   Characters of the username portion in a NAI MUST fulfill the
   requirements specified in [6]."

Is SASL-Prep the relevant authority here, or is this IEN?  In the
same vein:

Section 2.5 states:

"   As proposed in this document, the Network Access Identifier is of the
   form user@realm.  Please note that while the user portion of the NAI
   is based on the BNF described in [7], it has been extended for
   internationalization support as well as for purposes of Section 2.7,
   and is not necessarily compatible with the usernames used in e-mail.
   Note also that the internationalization requirements for NAIs and
   e-mail addresses are different, since the former need to be typed in
   only by the user himself and his own operator, not by others."

On the other hand, RFC 2486 states:

"Please note that while the user portion of the NAI conforms to the
BNF described in [5]"

[5] References RFC 822, the SMTP specification.  At the same time,
Section 4 indicates that there is no requirement that the NAI
represent a valid email address.  Perhaps we need to get a technical
advisor to assist us relating to these internationalization issues?

Section 2.8 does not list "[email-masked]" as a valid NAI, and
lists "@howard.edu" as an invalid NAI.  I'd restore the former example,
and given the privacy issues, the latter looks like it should be
valid now.

Author's addresses:  for this purpose my email should be:
[email-masked].

Section 4 says:

"   Note that the use of an FQDN as the realm name does not imply use of
   the DNS for location of the authentication server or for
   authentication routing.  Since to date roaming has been implemented
   on a relatively small scale, existing implementations typically
   handle location of authentication servers within a domain and perform
   authentication routing based on local knowledge expressed in proxy
   configuration files.  The implementations described in [8] have not
   found a need for use of DNS for location of the authentication server
   within a domain, although this can be accomplished via use of the DNS
   SRV record, described in [2].  Similarly, existing implementations
   have not found a need for dynamic routing protocols, or propagation
   of global routing information.  Note also that there is no
   requirement that the NAI represent a valid email address."

Note that roaming has been widely implemented at this point. I'd revise
this to say:

"  Note that the use of an FQDN as the realm name does not imply use of
   the DNS for location of the authentication server or for
   authentication routing.  Existing implementations typically
   handle location of authentication servers within a domain and perform
   authentication routing based on local knowledge expressed in proxy
   configuration files.  The implementations described in [8] have not
   found a need for use of DNS for location of the authentication server
   within a domain, although this can be accomplished via use of the DNS
   as described in [13].  Similarly, existing implementations
   have not found a need for dynamic routing protocols, or propagation
   of global routing information.  Note also that there is no
   requirement that that the NAI represent a valid email address."

Delete reference 2.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 17:52:31 +0000
Date: Thu, 25 Mar 2004 09:52:01 -0800
To: "Nelson, David" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: RADEXT charter, Take 8 

--=====================_41949049==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

David,

You said you wanted to look at specific issues:

Specifically looking at ARAP-Password and the attributes in Sterman or Prepaid

All these uses seem to gather related information together.

The only difference is the way the encoded the various Sub-Attributes that 
they contain.
ARAP uses fixed length encoding, while Prepaid and Sterman use TLV encoding.

ARAP doesn't break dictionaries.

Given the above I don't see what the problem is?

-Parviz

At 10:22 AM 3/25/2004 -0500, Nelson, David wrote:
>Parviz Yegani writes...
>
> > Why do you think that there is consensus against encoding
> > multiple data elements in a string attribute?
>
>Why?  Because RADIUS has always had a very simple, straightforward
>encoding of data elements in AVPs, in TLV format.  One data element; one
>attribute.
>
> > I agree with Wolfgang and others that someone must
> > show that structured string attributes would break existing
> > (standard-compliant) Radius implementations.
>
>Hmmm...  I guess if the evidence presented to date does not convince
>you, then it entirely possible that you will never be convinced.  Maybe
>it has to do with how one defines "break".  I define it as (a) deviation
>from the established protocol model, and (b) requiring changes to the
>protocol parsing engine of RADIUS implementations (as opposed the
>changes in the semantics enforcement engine, which is obviously required
>each time a new data element is introduced).
>
> > I agree with Avi's comment above that a string attribute containing
> > multiple elements of data
> > is already in common use in RADIUS and DIAMTER, no?
>
>For what definition of "common"?  Do you mean within RFCs approved by
>IETF Standards Action?
>
>-- Dave
>
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--=====================_41949049==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="arial" size=2>David,<br>
<br>
You said you wanted to look at specific issues:<br>
</font>&nbsp;<br>
<font face="arial" size=2>Specifically looking at ARAP-Password and the
attributes in Sterman or Prepaid<br>
</font>&nbsp;<br>
<font face="arial" size=2>All these uses seem to gather related
information together.<br>
</font>&nbsp;<br>
<font face="arial" size=2>The only difference is the way the encoded the
various Sub-Attributes that they contain.<br>
ARAP uses fixed length encoding, while Prepaid and Sterman use TLV
encoding.&nbsp; <br>
</font>&nbsp;<br>
<font face="arial" size=2>ARAP doesn't break dictionaries.<br>
</font>&nbsp;<br>
<font face="arial" size=2>Given the above I don't see what the problem
is?<br>
<br>
</font>-Parviz<br>
<br>
At 10:22 AM 3/25/2004 -0500, Nelson, David wrote:<br>
<blockquote type=cite cite>Parviz Yegani writes...<br>
<br>
&gt; Why do you think that there is consensus against encoding <br>
&gt; multiple data elements in a string attribute?<br>
<br>
Why?&nbsp; Because RADIUS has always had a very simple,
straightforward<br>
encoding of data elements in AVPs, in TLV format.&nbsp; One data element;
one<br>
attribute.<br>
<br>
&gt; I agree with Wolfgang and others that someone must<br>
&gt; show that structured string attributes would break existing <br>
&gt; (standard-compliant) Radius implementations.<br>
<br>
Hmmm...&nbsp; I guess if the evidence presented to date does not
convince<br>
you, then it entirely possible that you will never be convinced.&nbsp;
Maybe<br>
it has to do with how one defines &quot;break&quot;.&nbsp; I define it as
(a) deviation<br>
from the established protocol model, and (b) requiring changes to
the<br>
protocol parsing engine of RADIUS implementations (as opposed the<br>
changes in the semantics enforcement engine, which is obviously
required<br>
each time a new data element is introduced).<br>
<br>
&gt; I agree with Avi's comment above that a string attribute
containing<br>
&gt; multiple elements of data<br>
&gt; is already in common use in RADIUS and DIAMTER, no?<br>
<br>
For what definition of &quot;common&quot;?&nbsp; Do you mean within RFCs
approved by<br>
IETF Standards Action?<br>
<br>
-- Dave<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to [email-masked] 
with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive:
&lt;<a href="http://psg.com/lists/radiusext/" eudora="autourl">http://psg.com/lists/radiusext/</a>&gt;</blockquote></html>

--=====================_41949049==_.ALT--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 17:04:31 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: RADEXT charter, Take 8 
Date: Thu, 25 Mar 2004 12:03:55 -0500

> Parviz Yegani writes...
> 
> > Why do you think that there is consensus against encoding
> > multiple data elements in a string attribute?
> 
> Why?  Because RADIUS has always had a very simple, 
> straightforward encoding of data elements in AVPs, in TLV 
> format.  One data element; one attribute.

Really???????????????????????

Please explain the following:

Here I have listed all the attributes that explicitly contain multiple
elements in the same attribute.  I didn't even look at things like Strings
that should be opaque (class,state,eap message etc)

Use-Name
Chap-Password  IDENT + PASSWORD
Framed-Route   A list of IP-Addresses.
Vendor-Specific allows more then one attribute.
Tunnel-Password  Salt plust password
ARAP-Password  Multiple values 
ARAP-Features  Again multiple-values 
Connect-Info   a bunch of attributes.
Framed-IPv6-Prefix  Prefix-Length and Pre-fix
Framed-IPv6-Route   a list of ip addresses

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 15:48:59 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8 
Date: Thu, 25 Mar 2004 10:43:54 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Joel Halpern writes...

> I find this confusing.  Let us use prepaid as an example.  We are
> discussing an RFC on RADIUS prepaid.  This RFC defines a set of
behaviors
> to be used by RADIUS client and server.  It defines a set of AVPs to
be
> passed between these two entities.  None of the specification has any
> effect on the RADIUS processing logic, RADIUS routing, or RADIUS proxy
> behavior.  No devices which are not actively supporting pre-paid are
> affected by this work.  No new messages are introduced.

Are suggesting that there are two classes of RADIUS entities, (a) those
that need to understand pre-paid data elements, and (b) those that do
not?  That would seem to be the logical implication of your assertion
that complex, hybrid data elements (i.e. not "one data element, one
AVP") would not impact the "RADIUS processing logic". =20

I think I have heard others make this type of argument.  It goes along
the lines of "What harm is there in re-defining the RADIUS data formats,
since it's only RADIUS products manufactured to serve the pre-paid
market segment that would need to be modified to 'understand' the
content of these new formats?".

For my part, I reject the notion of two classes of RADIUS products.  You
either have multi-vendor interoperability in a protocol or you don't.
It's akin to the notion of being "partially pregnant" -- an oxymoron.

> Now, is that a RADIUS or Diameter RFC?  It seems that if we want to
> include opaque blobs of information we should declare that the=20
> description is not a RADIUS or Diameter RFC.  It would seem very odd
> to declare that this work needed to be done in a non-RADIUS=20
> non-Diameter working group since the only interesting supporting
> protocol is RADIUS.

Exactly to my point!  Either this is RADIUS or it isn't.  You can't have
it both ways.  By that, I mean that data elements can't be "out of
scope" for multi-vendor RADIUS protocol interoperability concerns and at
the same time "in scope" for the RADEXT WG.

> The distinction you are drawing (in a RADIUS or Diametter RFC) does
not
> seem to relate to any aspect of protocol compatibility or on the wire
> behavior.  Normally, the IETF tries to be more interested in whether
the
> protocols we define make sense on the wire than on how we label the
> documents we put them in.

You misunderstand my point.   The issue is not document labels, but
whether a data item communicated within RADIUS datagrams is "RADIUS" or
something else.  If it is RADIUS, it needs to be restricted to fall
within the approved and widely deployed RADIUS protocol architecture.
If it isn't RADIUS, it should be dealt with in another WG.

BTW, I wish to remind folks that the IETF has already dealt with the
question of defining a RADIUS-Plus protocol, in the early days of the
AAA WG.  That approach was rejected in favor of standardizing Diameter.
We ought not, IMHO, attempt to revive the notion of a RADIUS-Plus
protocol.  We are doing RADIUS Extensions, which implies a high level of
backwards compatibility.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 15:26:01 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8 
Date: Thu, 25 Mar 2004 10:22:42 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Parviz Yegani writes...

> Why do you think that there is consensus against encoding=20
> multiple data elements in a string attribute?

Why?  Because RADIUS has always had a very simple, straightforward
encoding of data elements in AVPs, in TLV format.  One data element; one
attribute.

> I agree with Wolfgang and others that someone must
> show that structured string attributes would break existing=20
> (standard-compliant) Radius implementations.

Hmmm...  I guess if the evidence presented to date does not convince
you, then it entirely possible that you will never be convinced.  Maybe
it has to do with how one defines "break".  I define it as (a) deviation
from the established protocol model, and (b) requiring changes to the
protocol parsing engine of RADIUS implementations (as opposed the
changes in the semantics enforcement engine, which is obviously required
each time a new data element is introduced).

> I agree with Avi's comment above that a string attribute containing
> multiple elements of data
> is already in common use in RADIUS and DIAMTER, no?

For what definition of "common"?  Do you mean within RFCs approved by
IETF Standards Action?

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 15:17:15 +0000
Date: Thu, 25 Mar 2004 10:16:39 -0500
To: <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: RADEXT charter, Take 8 

I find this confusing.  Let us use prepaid as an example.  We are 
discussing an RFC on RADIUS prepaid.  This RFC defines a set of behaviors 
to be used by RADIUS client and server.  It defines a set of AVPs to be 
passed between these two entities.  None of the specification has any 
effect on the RADIUS processing logic, RADIUS routing, or RADIUS proxy 
behavior.  No devices which are not actively supporting pre-paid are 
affected by this work.  No new messages are introduced.

Now, is that a RADIUS or Diameter RFC?  It seems that if we want to include 
opaque blobs of information we should declare that the description is not a 
RADIUS or Diameter RFC.  It would seem very odd to declare that this work 
needed to be done in a non-RADIUS non-Diameter working group since the only 
interesting supporting protocol is RADIUS.  And even more so since we would 
like to be consistent with the existing work in the DIAMETER space (subject 
to not introducing new messages and other RADIUS restrictions.)

The distinction you are drawing (in a RADIUS or Diametter RFC) does not 
seem to relate to any aspect of protocol compatibility or on the wire 
behavior.  Normally, the IETF tries to be more interested in whether the 
protocols we define make sense on the wire than on how we label the 
documents we put them in.

Yours,
Joel M. Halpern

PS: It is not impossible to define reasonable restrictions on the use of 
AVPs to avoid opening a pandora's box of complexity.  But the distinction 
proposed here does not seem to help.  And presumably it is not reasonable 
to declare that we need to wait a year while we reach agreement on what AVP 
forms are acceptable.  We need something simple.

At 08:10 AM 3/25/2004 -0500, Nelson, David wrote:
>I'm not sure I agree with your assessment, without reviewing the
>archive.  However, I think the key issues with consensus acceptance of
>strings is whether they fall into one of two cases: (a) limited parsing
>is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
>*ever* parse the strings, it passes them as opaque "binary blobs" to
>some other protocol, as in the case of EAP-Message.  In order to qualify
>as "some other protocol", the elements, syntax and semantics of that
>protocol can't be defined in a RADIUS or Diameter RFC.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 15:08:12 +0000
From: "Lila Madour (QA/EMC)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8
Date: Thu, 25 Mar 2004 09:05:17 -0600

Some small clarification inline..
/L

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Avi Lior
Sent: Wednesday, March 24, 2004 6:39 PM
To: [email-masked]'; Avi Lior
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8

Regarding external SDO requirements:

(Note this is not an official view of 3GPP2)

The current version of the prepaid document lines up with what 3GPP2 *has*
done.  Ideally we want to maintain compatibility with 3GPP2 while allowing
other people to add their requirements thus continuing interoperability with
3GPP2.

<Lila> The current version of the prepaid document does not line up completely with 3GPP2 published prepaid standard. For example, the use of service key does not exist in the published 3GPP2 standard. 

3GPP on the other hand will use Diameter CC.  There is requirement for
Diameter CC support for 3GPP2.  And we would probably want interop between a
RADIUS Prepaid solution and the Diameter prepaid solution in 3GPP2.  Note
that integration can happen many ways.  One method would be at the prepaid
server itself.  In this case you would have Diameter CC for IMS and RADIUS
prepaid for Packet Data both feeding off the same prepaid account.

WLAN Needs a prepaid solution.  We are pushing for this to be this method
(for reason stated in the current draft).

One thing to note is the I hope that we can do this a lot faster then the
current schedule. The reason is that prepaid is happening now big time.
Folks are starting to adopt this draft.  Dragging our feet will just make
the final work insignificant.

The current words in the charter reflect Diameter CC (specifically one time
event charging).  There is no need for that in 3GPP2 hence we currently
don't address that in the draft.  One time event charging maybe needed later
in 3GPP2.  Frankly I would like to know how that requirement got onto the
charter.

<Lila> I'm not sure if 3GPP2 needs one time event charging for packet data prepaid because 3GPP2 has not discussed the need of such requirement for packet data prepaid as of yet.  

Hope that helps....

Avi
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2004 4:07 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: RADEXT charter, Take 8
> 
> 
> Avi Lior wrote:
> 
> > Nothing is ever 100% compatible ;-)
> > 
> > As stated before, we are trying to keep the number of features and 
> > variations for the RADIUS prepaid document down so that we 
> can achieve 
> > the milestone set by the charter.
> > The approach taken would allow someone else to build on this work by
> > issueing a new RFC.
> > 
> > I am okay with the wording except the "Event Oriented 
> Charging" seems 
> > to be new.  That is in Diameter CC and not in this one.  The 
> > Differential charging (if I understand it correctly) can easily be 
> > addressed.
> > 
> > The two prepaid approaches (this one and diameter) share a common 
> > model. I had already received comments to that effect from serveral 
> > people who are quite interested in having equivalent 
> functionality.  
> > So we will keep working on this while maintaining the schedule.
> 
> Sounds good. Thanks for the info.
> 
> I agree with your approach to keep the number of
> features minimal. By the way, are there some external
> SDO requirements for this prepaid work? If so, is
> the charter definition for prepaid functions compatible
> with their requirements?
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 14:45:20 +0000
Date: Thu, 25 Mar 2004 06:45:03 -0800
To: "Nelson, David" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: RADEXT charter, Take 8 
Cc: avi Lior <[email-masked]>, [email-masked]

Hello, David,

Comments inline ...

At 08:10 AM 3/25/2004 -0500, Nelson, David wrote:
>Avi Lior writes...
>
> > 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.
>
>Lots?  Hmmm.  I agree that there are a few uses of string attributes, in
>which RADIUS or Diameter client/proxy/server implementations are
>expected to parse a string according to some syntax rules.  Most notably
>for routing decisions (e.g. NAI).  My point is that we ought not to open
>up the usage of string attributes that require parsing by RADIUS (or
>Diameter), in such a fashion that we've effectively abandoned the
>current TLV/AVP approach to structuring information.
>
>I'm not sure that continuing debate on this point in the abstract will
>shed any further light. It may be better to pick certain examples from
>the proposed drafts.

Good idea. Let's do 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.
>
>I'm not sure I agree with your assessment, without reviewing the
>archive.  However, I think the key issues with consensus acceptance of
>strings is whether they fall into one of two cases: (a) limited parsing
>is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
>*ever* parse the strings, it passes them as opaque "binary blobs" to
>some other protocol, as in the case of EAP-Message.  In order to qualify
>as "some other protocol", the elements, syntax and semantics of that
>protocol can't be defined in a RADIUS or Diameter RFC.
>
>To the extent that there is consensus against the usage of sub-types, in
>a non backward compatible fashion, I think there is also consensus
>against encoding the same sub-attributes in string values, as a way to
>"get around" the limitation.

Why do you think that there is consensus against encoding multiple data 
elements
in a string attribute? I agree with Wolfgang and others that someone must 
show that
structured string attributes would break existing (standard-compliant) Radius
implementations.

>To me, a sub-attribute is a sub-attribute, regardless of whether it is 
>encoded in
>a binary protocol fields or it is encoded in ASCII protocol fields.  If 
>RADIUS
>implementations need to change their data dictionary to decode the 
>sub-attributes,
>they will also need code changes to decode the same sub-attributes within the
>string format. That is my only point here.

I still don't understand why this would break Radius. Didn't you say/agree 
earlier that
there are a few uses of string attributes, in which RADIUS or 
Diameter  client/proxy/server
implementations are expected to parse a string according to some syntax 
rules? Does any
of these string attributes break Radius or Diameter?

I agree with Avi's comment above that a string attribute containing 
multiple elements of data
is already in common use in RADIUS and DIAMTER, no?

-Parviz

>Once again, we may have taken this debate as far as it can go in the
>abstract.  Further discussion should probably be couched in terms of
>comments on the drafts.
>
>I guess it should be obvious that the reason we are raising these
>meta-comments, in discussing the proposed charter, is that these issues
>will ultimately regulate the content of drafts that are eligible to
>become WG work items.
>
>-- Dave
>
>
>
>--
>to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 14:24:52 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: AW: interpreted vs un-interpreted attributes; RADEXT charter, Tak e 8 
Date: Thu, 25 Mar 2004 15:24:33 +0100

Dave wrote:
> However, I think the key issues with consensus acceptance of
> strings is whether they fall into one of two cases: (a) limited parsing
> is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
> *ever* parse the strings, it passes them as opaque "binary blobs" to
> some other protocol, as in the case of EAP-Message.  In order to qualify
> as "some other protocol", the elements, syntax and semantics of that
> protocol can't be defined in a RADIUS or Diameter RFC.

I'd like to modify your classification of RADIUS attributes a bit. We have
1) RADIUS attributes that must interpreted by the RADIUS server
2) RADIUS attributes where the RADIUS server just looks up/fills in values
from a database.

Your compatibility concerns are justified for type 2) attributes. Type 1)
attributes are interpreted anyway, so structured string attributes do
not any harm. CHAP and NAI are examples for type 1) attributes. In many
cases EAP falls in this category, too. It depends on the architecture
of RADIUS server software.

I've considered EAP for the HTTP digest problem. However, the idea of EAP
is that supplicants speak EAP and the NAS just tunnels it to the RADIUS
server. Unfortunately todays' SIP clients don't support EAP, so the NAS
would have to put HTTP Digest parameters into a fresh EAP message. It
would work, but I am not sure whether EAP people would like it.

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 14:01:00 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8
Date: Thu, 25 Mar 2004 08:56:28 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> The current version of the prepaid document lines up with what 3GPP2
*has*
> done.  Ideally we want to maintain compatibility with 3GPP2 while
allowing
> other people to add their requirements thus continuing
interoperability
> with 3GPP2.

<snip>=20

> One thing to note is the I hope that we can do this a lot faster then
the
> current schedule. The reason is that prepaid is happening now big
time.
> Folks are starting to adopt this draft.  Dragging our feet will just
make
> the final work insignificant.=20

The current proposed charter gives us two options for dealing with this
issue.

(1) Maintain [some level of] compatibility with the 3GPP2 document (and
other similar documents) that bend the current IETF-sanctioned RADIUS
protocol architecture, virtually to the breaking point, certainly
introducing substantial backwards compatibility and multi-vendor
interoperability issues.  The charter proposal allows this to occur
*only* after design and interoperability guidelines have been written
and the thorny backwards compatibility issues have been thoroughly
studied and understood.  This will take a substantial investment of time
and energy.

(2) Basically admit that the 3GPP2 approach (and similar approaches) do
not fall within the current IETF-sanctioned RADIUS protocol architecture
and revise the relevant [WG] drafts so that the same functionality is
achieved, but in a fashion that maintains backward compatibility and
multi-vendor interoperability, and conformance with the current
implementations and architecture.  This approach can move forward
relatively quickly.

There is no viable third approach, IMHO, that achieves the protocol
outcome of approach (1) with the schedule outcome of approach (2).
That, again IMHO, would be tantamount to the IETF simply "rubber
stamping" work that had been done elsewhere, possibly without much
Internet Community review, and would fail to address the traditional
requirements for extensions to IETF Standards Track protocols.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 13:13:07 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8 
Date: Thu, 25 Mar 2004 08:10:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> 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=20
> lots of examples of that.

Lots?  Hmmm.  I agree that there are a few uses of string attributes, in
which RADIUS or Diameter client/proxy/server implementations are
expected to parse a string according to some syntax rules.  Most notably
for routing decisions (e.g. NAI).  My point is that we ought not to open
up the usage of string attributes that require parsing by RADIUS (or
Diameter), in such a fashion that we've effectively abandoned the
current TLV/AVP approach to structuring information.

I'm not sure that continuing debate on this point in the abstract will
shed any further light. It may be better to pick certain examples from
the proposed drafts.

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

I'm not sure I agree with your assessment, without reviewing the
archive.  However, I think the key issues with consensus acceptance of
strings is whether they fall into one of two cases: (a) limited parsing
is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
*ever* parse the strings, it passes them as opaque "binary blobs" to
some other protocol, as in the case of EAP-Message.  In order to qualify
as "some other protocol", the elements, syntax and semantics of that
protocol can't be defined in a RADIUS or Diameter RFC.

To the extent that there is consensus against the usage of sub-types, in
a non backward compatible fashion, I think there is also consensus
against encoding the same sub-attributes in string values, as a way to
"get around" the limitation.  To me, a sub-attribute is a sub-attribute,
regardless of whether it is encoded in a binary protocol fields or it is
encoded in ASCII protocol fields.  If RADIUS implementations need to
change their data dictionary to decode the sub-attributes, they will
also need code changes to decode the same sub-attributes within the
string format. That is my only point here.

Once again, we may have taken this debate as far as it can go in the
abstract.  Further discussion should probably be couched in terms of
comments on the drafts.

I guess it should be obvious that the reason we are raising these
meta-comments, in discussing the proposed charter, is that these issues
will ultimately regulate the content of drafts that are eligible to
become WG work items.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 07:58:37 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: AW: structured string attributes,  RADEXT charter, Take 8
Date: Thu, 25 Mar 2004 08:58:08 +0100

Dave wrote:
> 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?
No. My position is that there are attributes that don't make sense if they are
used alone.

For example, User-Name can be used with or without User-Password.
So, User-Name and User-Password are separate attributes.

On the other hand CHAP ident and CHAP response only make sense if they are used
together. So somebody grouped them into a single attribute. The same applies
for the HTTP digest extension.

The last draft charter says, that anybody proposing structured string attributes
must show that this does not break existing RfC-compliant implementations. I think
we are both - for different reasons - not very happy about it. This is one definition
of a compromise.

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 03:49:16 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Jari Arkko <[email-masked]>
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8
Date: Wed, 24 Mar 2004 22:49:09 -0500

That's right because 3GPP2 packet data prepaid does not currently require
Event Based Charging and 3GPP2 MMD may require it but they would get it via
Diameter.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2004 9:51 PM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: RADEXT charter, Take 8
> 
> 
> > > features minimal. By the way, are there some external
> > > SDO requirements for this prepaid work? If so, is
> > > the charter definition for prepaid functions compatible 
> with their 
> > > requirements?
> >
> > Actually, the features (including event-related charging) 
> came from a 
> > liaison request from 3GPP2.
> 
> Correction. I went back over my notes and the request came in 
> as a comment from a participant on the RADEXT mailing list.  
> I will let the person who made the suggestion provide the 
> logic behind it.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 03:37:18 +0000
From: Avi Lior <[email-masked]>
To: "'Joel M. Halpern'" <[email-masked]>, [email-masked]
Subject: RE: RADEXT charter, Take 8
Date: Wed, 24 Mar 2004 22:36:49 -0500

Thanx Joel,

Just to make it perfectly clear, that in both the Sterman Draft and Perpaid
draft we are absolutely *not* introducing a new RADIUS attribute type.  What
we are doing is encoding the information in an attribute of type String.
Since Strings are supported by RADIUS dictionaries all intermediaries can
process the attribute at least to that level.

In both Prepaid and Sterman, and in similar cases such as EAP, there is no
intent for this attribute to be processed by any entity other than the two
end points.

I cant see how this usage breaks RADIUS, nor even that it qualifies to be
discused as a case for requireing a new RADIUS Subtypes.

Looking over previous emails, Randy Bush the said the following about the
Prepaid Draft:
" For
       example, it creates a new RADIUS attribute format including
       support for "sub-attributes," supposedly because the draft
       would otherwise require so many attributes that it would
       exhaust the entire RADIUS attribute space. "

This is absolutely not true.  Neither draft create a new RADIUS attribute
format.  The attribute is of type STRING in both drafts.

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2004 9:51 PM
> To: [email-masked]
> Subject: Re: RADEXT charter, Take 8
> 
> 
> I was having some side conversations about RADIUS usage for 
> prepaid, and 
> wrote the following comment.  Given the current discussions 
> about whether 
> event charging belongs in the charter, and whether subtypes 
> belong within 
> scope, it seems that the comment belongs on the list.
> 
> 
> The RFPs we are seeing from Cellular (CDMA and GPRS) 
> operators call for 
> differential charging and time, volume, and event charging.  
> Obviously, 
> they do not care about whether a flat attribute space or 
> sub-attributes are 
> used.  But they do need more information exchanged than just 
> start time, 
> expiration time, and stop time.
> If the charter item is intended to allow that, then I am 
> happy to separate 
> the question of how the information should be structured from 
> the question 
> of whether the problem is in scope or not.
> 
> 
> It does seem to me given the complexity of the necessary 
> information that 
> this does lead to allowing one level of subtype support within new 
> attributes.  And it does seem to me that such usage is 
> backwards compatible 
> with RADIUS RFCs.
> 
> Yours,
> Joel
> 
> At 07:34 PM 3/23/2004 -0800, Bernard Aboba wrote:
> >- Pre-paid support.  Prepaid services are contemplated in a number
> >   of potential applications, including wireless LAN access and IP
> >   telephony.  In order to enable support of pre-paid services in an
> >   interoperable way, the WG will provide definitions of the
> >   attributes required to support operator service models for
> >   pre-paid, as documented in liaison communications.  Support
> >   will be included for time, volume, and event oriented charging
> >   as well as support for limited differential charging.
> >   This document will be compatible with Diameter Credit Control.
> >
> >...
> >
> >* All drafts will need to undergo review prior to acceptance 
> as WG work
> >   items, which includes demonstration that the drafts are backward
> >   compatible with RADIUS RFCs and are compatible with equivalent
> >   facilities in Diameter.  Given the backwards 
> compatibility issues, no
> >   document including sub-attributes will be considered for 
> publication as
> >   an RFC before the RADIUS design guidelines and RADIUS/Diameter
> >   translation work items are completed, analyzing the issues in
> >   a comprehensive way.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 02:51:07 +0000
Date: Wed, 24 Mar 2004 21:50:30 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: RADEXT charter, Take 8

I was having some side conversations about RADIUS usage for prepaid, and 
wrote the following comment.  Given the current discussions about whether 
event charging belongs in the charter, and whether subtypes belong within 
scope, it seems that the comment belongs on the list.

The RFPs we are seeing from Cellular (CDMA and GPRS) operators call for 
differential charging and time, volume, and event charging.  Obviously, 
they do not care about whether a flat attribute space or sub-attributes are 
used.  But they do need more information exchanged than just start time, 
expiration time, and stop time.
If the charter item is intended to allow that, then I am happy to separate 
the question of how the information should be structured from the question 
of whether the problem is in scope or not.

It does seem to me given the complexity of the necessary information that 
this does lead to allowing one level of subtype support within new 
attributes.  And it does seem to me that such usage is backwards compatible 
with RADIUS RFCs.

Yours,
Joel

At 07:34 PM 3/23/2004 -0800, Bernard Aboba wrote:
>- Pre-paid support.  Prepaid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony.  In order to enable support of pre-paid services in an
>   interoperable way, the WG will provide definitions of the
>   attributes required to support operator service models for
>   pre-paid, as documented in liaison communications.  Support
>   will be included for time, volume, and event oriented charging
>   as well as support for limited differential charging.
>   This document will be compatible with Diameter Credit Control.
>
>...
>
>* All drafts will need to undergo review prior to acceptance as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.  Given the backwards compatibility issues, no
>   document including sub-attributes will be considered for publication as
>   an RFC before the RADIUS design guidelines and RADIUS/Diameter
>   translation work items are completed, analyzing the issues in
>   a comprehensive way.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 02:43:05 +0000
Date: Wed, 24 Mar 2004 18:51:23 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: RADEXT charter, Take 8

> > features minimal. By the way, are there some external
> > SDO requirements for this prepaid work? If so, is
> > the charter definition for prepaid functions compatible
> > with their requirements?
>
> Actually, the features (including event-related charging) came from a
> liaison request from 3GPP2.

Correction. I went back over my notes and the request came in as a comment
from a participant on the RADEXT mailing list.  I will let the person who
made the suggestion provide the logic behind it.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 02:34:51 +0000
Date: Wed, 24 Mar 2004 18:42:50 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: RADEXT charter, Take 8

> Sounds good. Thanks for the info.
>
> I agree with your approach to keep the number of
> features minimal. By the way, are there some external
> SDO requirements for this prepaid work? If so, is
> the charter definition for prepaid functions compatible
> with their requirements?

Actually, the features (including event-related charging) came from a
liaison request from 3GPP2.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 25 Mar 2004 00:20:43 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: RADEXT charter, Take 8 
Date: Wed, 24 Mar 2004 19:20:34 -0500

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:[email-masked]] 
> Sent: Wednesday, March 24, 2004 4:59 PM
> To: [email-masked]
> 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 
> [email-masked] 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 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 23:38:59 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8
Date: Wed, 24 Mar 2004 18:38:38 -0500

Regarding external SDO requirements:

(Note this is not an official view of 3GPP2)

The current version of the prepaid document lines up with what 3GPP2 *has*
done.  Ideally we want to maintain compatibility with 3GPP2 while allowing
other people to add their requirements thus continuing interoperability with
3GPP2.

3GPP on the other hand will use Diameter CC.  There is requirement for
Diameter CC support for 3GPP2.  And we would probably want interop between a
RADIUS Prepaid solution and the Diameter prepaid solution in 3GPP2.  Note
that integration can happen many ways.  One method would be at the prepaid
server itself.  In this case you would have Diameter CC for IMS and RADIUS
prepaid for Packet Data both feeding off the same prepaid account.

WLAN Needs a prepaid solution.  We are pushing for this to be this method
(for reason stated in the current draft).

One thing to note is the I hope that we can do this a lot faster then the
current schedule. The reason is that prepaid is happening now big time.
Folks are starting to adopt this draft.  Dragging our feet will just make
the final work insignificant.

The current words in the charter reflect Diameter CC (specifically one time
event charging).  There is no need for that in 3GPP2 hence we currently
don't address that in the draft.  One time event charging maybe needed later
in 3GPP2.  Frankly I would like to know how that requirement got onto the
charter.

Hope that helps....

Avi
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2004 4:07 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: RADEXT charter, Take 8
> 
> 
> Avi Lior wrote:
> 
> > Nothing is ever 100% compatible ;-)
> > 
> > As stated before, we are trying to keep the number of features and 
> > variations for the RADIUS prepaid document down so that we 
> can achieve 
> > the milestone set by the charter.
> > The approach taken would allow someone else to build on this work by
> > issueing a new RFC.
> > 
> > I am okay with the wording except the "Event Oriented 
> Charging" seems 
> > to be new.  That is in Diameter CC and not in this one.  The 
> > Differential charging (if I understand it correctly) can easily be 
> > addressed.
> > 
> > The two prepaid approaches (this one and diameter) share a common 
> > model. I had already received comments to that effect from serveral 
> > people who are quite interested in having equivalent 
> functionality.  
> > So we will keep working on this while maintaining the schedule.
> 
> Sounds good. Thanks for the info.
> 
> I agree with your approach to keep the number of
> features minimal. By the way, are there some external
> SDO requirements for this prepaid work? If so, is
> the charter definition for prepaid functions compatible
> with their requirements?
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 22:08:13 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8 
Date: Wed, 24 Mar 2004 16:58:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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. =20

*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

>=20
>=20
> Wolfgang
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 21:29:08 +0000
To: [email-masked]
Subject: Re: RADEXT charter, Take 8 
Date: Wed, 24 Mar 2004 22:28:31 +0100
From: [email-masked] (Wolfgang Beck)

Jari wrote:
> Bernard wrote:
> > - SIP support.  RADIUS is currently used for SIP authentication,
> >   authorization and accounting.  Standardization of these attributes
> >   will enable improved interoperability.
> 
> I'd like to add something about compatibility with existing
> IETF RFCs on HTTP Digest on this...
> 
> Also, add something about compatibility. I think the functionality
> of Diameter SIP is bigger than in RADIUS SIP, so maybe a note
> about not necessarily being able to translate from Diameter to
> RADIUS in all cases is appropriate.
> [..]
> So I would prefer seeing a "Diameter Translation Considerations"
> section in the RADIUS SIP extension, for instance. I'll volunteer
> again...
This is already on my list for version -02 of the HTTP Digest draft.

Jari wrote:
> Bernard wrote:
> > * All drafts will need to undergo review prior to acceptance as WG work
> >   items, which includes demonstration that the drafts are backward
> >   compatible with RADIUS RFCs and are compatible with equivalent
> >   facilities in Diameter.  Given the backwards compatibility issues, no
> >   document including sub-attributes will be considered for publication as
> >   an RFC before the RADIUS design guidelines and RADIUS/Diameter
> >   translation work items are completed, analyzing the issues in
> >   a comprehensive way.
> 
> I think this approach to subattributes makes sense.
> 
If this does not translate into 'string attributes must not be structured',
I can live with it. You know my opinion about this.

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 21:09:54 +0000
Date: Wed, 24 Mar 2004 23:06:47 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT charter, Take 8

Avi Lior wrote:

> Nothing is ever 100% compatible ;-)
> 
> As stated before, we are trying to keep the number of features and
> variations for the RADIUS prepaid document down so that we can achieve the
> milestone set by the charter.  
> The approach taken would allow someone else to build on this work by
> issueing a new RFC.
> 
> I am okay with the wording except the "Event Oriented Charging" seems to be
> new.  That is in Diameter CC and not in this one.  The Differential charging
> (if I understand it correctly) can easily be addressed.
> 
> The two prepaid approaches (this one and diameter) share a common model. I
> had already received comments to that effect from serveral people who are
> quite interested in having equivalent functionality.  So we will keep
> working on this while maintaining the schedule. 

Sounds good. Thanks for the info.

I agree with your approach to keep the number of
features minimal. By the way, are there some external
SDO requirements for this prepaid work? If so, is
the charter definition for prepaid functions compatible
with their requirements?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 17:17:32 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: RE: RADEXT charter, Take 8
Date: Wed, 24 Mar 2004 12:16:59 -0500

Comment on Jari's prepaid.

> > - Pre-paid support.  Prepaid services are contemplated in a number
> >   of potential applications, including wireless LAN access and IP
> >   telephony.  In order to enable support of pre-paid services in an
> >   interoperable way, the WG will provide definitions of the
> >   attributes required to support operator service models for
> >   pre-paid, as documented in liaison communications.  Support
> >   will be included for time, volume, and event oriented charging
> >   as well as support for limited differential charging.
> >   This document will be compatible with Diameter Credit Control.
> 
> Question to prepaid experts: how compatible? 100%, or is 
> there some function in RADIUS prepaid or Diameter prepaid 
> that is not being planned for the other? I hope the basic 
> models are compatible at least.
>

Nothing is ever 100% compatible ;-)

As stated before, we are trying to keep the number of features and
variations for the RADIUS prepaid document down so that we can achieve the
milestone set by the charter.  
The approach taken would allow someone else to build on this work by
issueing a new RFC.

I am okay with the wording except the "Event Oriented Charging" seems to be
new.  That is in Diameter CC and not in this one.  The Differential charging
(if I understand it correctly) can easily be addressed.

The two prepaid approaches (this one and diameter) share a common model. I
had already received comments to that effect from serveral people who are
quite interested in having equivalent functionality.  So we will keep
working on this while maintaining the schedule. 

Hope this helps.

Avi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 09:16:37 +0000
Date: Wed, 24 Mar 2004 11:13:24 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT charter, Take 8

Hi Bernard, and thanks for posting the updated
charters. Comments inline, followed by a suggested
modified charter text at the end.

Bernard Aboba wrote:
> RADIUS Extensions Working Group (RADEXT) Charter
> Last Modified: 2004-03-23

I still think the name is misleading. Three out of
your seven work items are generic items not necessarily
tied to just RADIUS (NAIbis, translation, and LAN
attributes).

> Chair(s):
> David Nelson <[email-masked]>
> 
> Operations and Management Area Director(s):
> David Kessens <[email-masked]>
> Bert Wijnen <[email-masked]>
> 
> Operations and Management Area Advisor:
> David Kessens <[email-masked]>
> 
> Technical Advisor:
> Paul Congdon <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
> 
> Description of Working Group:
> 
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as IP telephony and Local Area Network authentication, authorization
> and accounting.
> 
> In order to ensure backward compatibility with RADIUS as well as
> Diameter, the following restrictions are imposed on extensions considered
> by the RADIUSEXT WG:
> 
> - All work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
> - All work MUST be compatible with equivalent facilities in Diameter.

Where new facilities are being defined as attributes, these should
be designed in a manner that makes it possible to use the same
attribute definitions in both protocols. I'll volunteer to
contribute...

> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> 
> Work Items
> 
> The immediate goals of the RADIUSEXT working group are to address the
> following issues:
> 
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
>   document will also review RADIUS data types and associated
>   backwards compatibility issues.
> 
> - RADIUS/Diameter translation.  This document will describe the
>   best current practices for RADIUS/Diameter translation.

Hmm... unfortunately I tend to think that beyond what Diameter
NASREQ says, this is quite application specific.

Basically, your problem is that the minute someone brings another
application to the table, the translation document suddenly needs
another revision. Also, if the translation issues were handled
per application, it would be easier to ensure that the design
of the applications makes the translation easy.

So I would prefer seeing a "Diameter Translation Considerations"
section in the RADIUS SIP extension, for instance. I'll volunteer
again...

> - Revised NAI specification.  This document, known as "RFC 2486bis"
>   will revise the NAI specification to provide more details on
>   routing as well as handling internationalization.

Add something about fixing errors, that is an important part
of the revision. What about privacy support, or did you include
that under "routing"?

> - Pre-paid support.  Prepaid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony.  In order to enable support of pre-paid services in an
>   interoperable way, the WG will provide definitions of the
>   attributes required to support operator service models for
>   pre-paid, as documented in liaison communications.  Support
>   will be included for time, volume, and event oriented charging
>   as well as support for limited differential charging.
>   This document will be compatible with Diameter Credit Control.

Question to prepaid experts: how compatible? 100%, or is there
some function in RADIUS prepaid or Diameter prepaid that is
not being planned for the other? I hope the basic models are
compatible at least.

> - SIP support.  RADIUS is currently used for SIP authentication,
>   authorization and accounting.  Standardization of these attributes
>   will enable improved interoperability.

I'd like to add something about compatibility with existing
IETF RFCs on HTTP Digest on this...

Also, add something about compatibility. I think the functionality
of Diameter SIP is bigger than in RADIUS SIP, so maybe a note
about not necessarily being able to translate from Diameter to
RADIUS in all cases is appropriate.

> - LAN attributes.  New attributes have been proposed to enable use of
>   RADIUS authentication, authorization and accounting in wired and
>   wireless LANs.  Standardization of these attributes will enable
>   improved interoperability.
> 
> - MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
>   changes are required to address this issue.
> 
> Goals and Milestones:
> 
> Dec 04  Updated RADIUS MIBs submitted for publication.
> Dec 04  SIP authentication draft submitted as a Proposed Standard RFC.
> Feb 05  WLAN attributes submitted as a Proposed Standard RFC.
> Feb 05  RFC 2486bis submitted as a Proposed Standard.

I'd prefer seeing this work ready sooner but I consistently surprise
myself how long everything takes, especially for my own drafts ;-)

OTOH, the charter does not prevent work being finished sooner...

> Dec 05  RADIUS design guidelines submitted as an Informational RFC.
> Dec 05  RADIUS/Diameter translation document submitted as a BCP.
> Dec 05  LAN attributes submitted as a Proposed Standard RFC.
> Dec 05  Prepaid draft submitted as a Proposed Standard RFC.
> 
> Quality Control Plan

The IESG will (unfortunately) strip the QC plan from the
charter when they approve it, I have recent experience
from this... nevertheless, I believe its valuable to keep
it in the proposed charter and it should be followed later
in the work.

> In order to ensure quality of work:
> 
> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
> 
> * All drafts will need to undergo review prior to acceptance as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.  Given the backwards compatibility issues, no
>   document including sub-attributes will be considered for publication as
>   an RFC before the RADIUS design guidelines and RADIUS/Diameter
>   translation work items are completed, analyzing the issues in
>   a comprehensive way.

I think this approach to subattributes makes sense.

> * The WG will utilize an automated issue tracking system.
> 
> * XML to RFC will be used in production of documents.  This enables
>   production of HTML and text files from a single source file as
>   well as automated production of difference files.

Based on the above comments, I'd like to suggest the
following text as the charter:

AAA Extensions Working Group (AAAEXT) Charter
Last Modified: 2004-03-24

Chair(s):
David Nelson <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The AAA Extensions Working Group will focus on maintaining
AAA related specifications, adding support for the use of
AAA protocols (RADIUS, Diameter) for Local Area Network
authentication, authorization, and accounting, and adding
support to the RADIUS porocol for IP telephony and prepaid
applications.

In order to ensure backward compatibility with RADIUS as well as
Diameter, the following restrictions are imposed on extensions
considered by the WG:

- All work MUST be backward compatible with existing RADIUS RFCs,
   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
   and 3580.

- All extensions consisting of carrying additional information
   attributes MUST be defined in a manner suitable for the use
   of the same attributes in both RADIUS and Diameter.

- All other work MUST be compatible with equivalent facilities in
   Diameter, if such facilities already exist. A Diameter Translation
   Considerations section MUST be provided to describe the mapping
   that a RADIUS-Diameter translation gateway would have to implement.

- The RADIUS maximum packet size (4K) will not be increased.

- No new RADIUS transports (e.g. TCP, SCTP) will be defined.

Work Items

The immediate goals of the AAAEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
   for design of RADIUS attributes, including discussion of the
   appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
   document will also review RADIUS data types and associated
   backwards compatibility issues.

- Revised NAI specification.  This document, known as "RFC 2486bis"
   will revise the NAI specification to correct known errors,
   provide more details on routing, add support for privacy,
   as well as handling internationalization.

- Pre-paid support.  Prepaid services are contemplated in a number
   of potential applications, including wireless LAN access and IP
   telephony.  In order to enable support of pre-paid services in an
   interoperable way, the WG will provide definitions of the
   attributes required to support operator service models for
   pre-paid, as documented in liaison communications.  Support
   will be included for time, volume, and event oriented charging
   as well as support for limited differential charging.
   This document will be compatible with Diameter Credit Control.

- SIP support.  RADIUS is currently used for SIP authentication,
   authorization and accounting.  Standardization of these attributes
   will enable improved interoperability.

   This document will be compatible with existing IETF RFCs
   on HTTP Digest, including RFC 2617, 3261, and 3310.

   This document will be compatible with Diameter SIP application,
   but not necessarily vice versa, as the Diameter SIP application
   supports additional functionality such as routing.

- LAN attributes.  New attributes have been proposed to enable use of
   authentication, authorization and accounting in wired and wireless LANs.
   Standardization of these attributes will enable improved
   interoperability. These attributes are defined in a manner where
   their use in both RADIUS and Diameter is possible through the
   same document.

- MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
   changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Dec 04  SIP authentication draft submitted as a Proposed Standard RFC.
Dec 04  RFC 2486bis submitted as a Proposed Standard.
Feb 05  WLAN attributes submitted as a Proposed Standard RFC.
Dec 05  RADIUS design guidelines submitted as an Informational RFC.
Dec 05  LAN attributes submitted as a Proposed Standard RFC.
Dec 05  Prepaid draft submitted as a Proposed Standard RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
   demonstrated to be available to guarantee a high probability of
   success.  This includes recruitment of a core of editors and
   reviewers with significant IETF experience and demonstrated time
   commitment.

* All drafts will need to undergo review prior to acceptance as WG work
   items, which includes demonstration that the drafts are backward
   compatible with RADIUS RFCs and are compatible with equivalent
   facilities in Diameter.  Given the backwards compatibility issues, no
   document including sub-attributes will be considered for publication as
   an RFC before the RADIUS design guidelines and RADIUS/Diameter
   translation work items are completed, analyzing the issues in
   a comprehensive way.

* The WG will utilize an automated issue tracking system.

* XML to RFC will be used in production of documents.  This enables
   production of HTML and text files from a single source file as
   well as automated production of difference files.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 03:34:59 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter, Take 8
Date: Wed, 24 Mar 2004 05:34:52 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard,

Looks OK to me.=20

I have two editorial comments:
- would be useful to list references for the 'equivalent facilities' in =
Diameter (as done for the existing RADIUS RFCs)
- the first paragraph in the Quality Control Plan - this WG will not be =
chartered until...' will become not relevant after the Charter is =
approved. I have no problem with its content, it just cannot be part of =
the Charter.

Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: 24 March, 2004 5:34 AM
> To: [email-masked]
> Subject: RADEXT charter, Take 8
>=20
>=20
> RADIUS Extensions Working Group (RADEXT) Charter
> Last Modified: 2004-03-23
>=20
> Chair(s):
> David Nelson <[email-masked]>
>=20
> Operations and Management Area Director(s):
> David Kessens <[email-masked]>
> Bert Wijnen <[email-masked]>
>=20
> Operations and Management Area Advisor:
> David Kessens <[email-masked]>
>=20
> Technical Advisor:
> Paul Congdon <[email-masked]>
>=20
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], In Body: subscribe
> Archive: http://ops.ietf.org/lists/radiusext
>=20
> Description of Working Group:
>=20
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as IP telephony and Local Area Network authentication,=20
> authorization
> and accounting.
>=20
> In order to ensure backward compatibility with RADIUS as well as
> Diameter, the following restrictions are imposed on=20
> extensions considered
> by the RADIUSEXT WG:
>=20
> - All work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576,=20
> 3579, and 3580.
> - All work MUST be compatible with equivalent facilities in Diameter.
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
>=20
> Work Items
>=20
> The immediate goals of the RADIUSEXT working group are to address the
> following issues:
>=20
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
>   document will also review RADIUS data types and associated
>   backwards compatibility issues.
>=20
> - RADIUS/Diameter translation.  This document will describe the
>   best current practices for RADIUS/Diameter translation.
>=20
> - Revised NAI specification.  This document, known as "RFC 2486bis"
>   will revise the NAI specification to provide more details on
>   routing as well as handling internationalization.
>=20
> - Pre-paid support.  Prepaid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony.  In order to enable support of pre-paid services in an
>   interoperable way, the WG will provide definitions of the
>   attributes required to support operator service models for
>   pre-paid, as documented in liaison communications.  Support
>   will be included for time, volume, and event oriented charging
>   as well as support for limited differential charging.
>   This document will be compatible with Diameter Credit Control.
>=20
> - SIP support.  RADIUS is currently used for SIP authentication,
>   authorization and accounting.  Standardization of these attributes
>   will enable improved interoperability.
>=20
> - LAN attributes.  New attributes have been proposed to enable use of
>   RADIUS authentication, authorization and accounting in wired and
>   wireless LANs.  Standardization of these attributes will enable
>   improved interoperability.
>=20
> - MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
>   changes are required to address this issue.
>=20
> Goals and Milestones:
>=20
> Dec 04  Updated RADIUS MIBs submitted for publication.
> Dec 04  SIP authentication draft submitted as a Proposed Standard RFC.
> Feb 05  WLAN attributes submitted as a Proposed Standard RFC.
> Feb 05  RFC 2486bis submitted as a Proposed Standard.
> Dec 05  RADIUS design guidelines submitted as an Informational RFC.
> Dec 05  RADIUS/Diameter translation document submitted as a BCP.
> Dec 05  LAN attributes submitted as a Proposed Standard RFC.
> Dec 05  Prepaid draft submitted as a Proposed Standard RFC.
>=20
> Quality Control Plan
>=20
> In order to ensure quality of work:
>=20
> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
>=20
> * All drafts will need to undergo review prior to acceptance=20
> as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.  Given the backwards compatibility=20
> issues, no
>   document including sub-attributes will be considered for=20
> publication as
>   an RFC before the RADIUS design guidelines and RADIUS/Diameter
>   translation work items are completed, analyzing the issues in
>   a comprehensive way.
>=20
> * The WG will utilize an automated issue tracking system.
>=20
> * XML to RFC will be used in production of documents.  This enables
>   production of HTML and text files from a single source file as
>   well as automated production of difference files.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Mar 2004 03:26:11 +0000
Date: Tue, 23 Mar 2004 19:34:14 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT charter, Take 8

RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-03-23

Chair(s):
David Nelson <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions
to the RADIUS protocol required to enable its use in applications
such as IP telephony and Local Area Network authentication, authorization
and accounting.

In order to ensure backward compatibility with RADIUS as well as
Diameter, the following restrictions are imposed on extensions considered
by the RADIUSEXT WG:

- All work MUST be backward compatible with existing RADIUS RFCs,
  including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All work MUST be compatible with equivalent facilities in Diameter.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.

Work Items

The immediate goals of the RADIUSEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
  for design of RADIUS attributes, including discussion of the
  appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
  document will also review RADIUS data types and associated
  backwards compatibility issues.

- RADIUS/Diameter translation.  This document will describe the
  best current practices for RADIUS/Diameter translation.

- Revised NAI specification.  This document, known as "RFC 2486bis"
  will revise the NAI specification to provide more details on
  routing as well as handling internationalization.

- Pre-paid support.  Prepaid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony.  In order to enable support of pre-paid services in an
  interoperable way, the WG will provide definitions of the
  attributes required to support operator service models for
  pre-paid, as documented in liaison communications.  Support
  will be included for time, volume, and event oriented charging
  as well as support for limited differential charging.
  This document will be compatible with Diameter Credit Control.

- SIP support.  RADIUS is currently used for SIP authentication,
  authorization and accounting.  Standardization of these attributes
  will enable improved interoperability.

- LAN attributes.  New attributes have been proposed to enable use of
  RADIUS authentication, authorization and accounting in wired and
  wireless LANs.  Standardization of these attributes will enable
  improved interoperability.

- MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
  changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Dec 04  SIP authentication draft submitted as a Proposed Standard RFC.
Feb 05  WLAN attributes submitted as a Proposed Standard RFC.
Feb 05  RFC 2486bis submitted as a Proposed Standard.
Dec 05  RADIUS design guidelines submitted as an Informational RFC.
Dec 05  RADIUS/Diameter translation document submitted as a BCP.
Dec 05  LAN attributes submitted as a Proposed Standard RFC.
Dec 05  Prepaid draft submitted as a Proposed Standard RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
  demonstrated to be available to guarantee a high probability of
  success.  This includes recruitment of a core of editors and
  reviewers with significant IETF experience and demonstrated time
  commitment.

* All drafts will need to undergo review prior to acceptance as WG work
  items, which includes demonstration that the drafts are backward
  compatible with RADIUS RFCs and are compatible with equivalent
  facilities in Diameter.  Given the backwards compatibility issues, no
  document including sub-attributes will be considered for publication as
  an RFC before the RADIUS design guidelines and RADIUS/Diameter
  translation work items are completed, analyzing the issues in
  a comprehensive way.

* The WG will utilize an automated issue tracking system.

* XML to RFC will be used in production of documents.  This enables
  production of HTML and text files from a single source file as
  well as automated production of difference files.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Mar 2004 17:43:54 +0000
Date: Tue, 23 Mar 2004 19:40:57 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: Re: Private NAIs (Was: Re: rfc2486bis)

Bernard Aboba wrote:

> Relaxing the requirement on FQDN allocation would open up a can of worms
> that is best left closed.  For example, Diameter can use DNS for service
> location; if the NAI realms are "private" then this will break.  Also, allocation of
> "private" realms would presumably require a description of which realms
> are "private" in order to reserve them.  The IETF does not in general
> have the authority to allocate FQDNs -- that's the purview of ICANN.

I agree. If you think the requirement should be clarified
(I guess this discussion is a proof that some clarification
may be needed), would you prefer a MUST or a SHOULD?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Mar 2004 15:48:43 +0000
content-class: urn:content-classes:message
Subject: RE: rfc2486bis
Date: Tue, 23 Mar 2004 15:25:27 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi,

My interpretation of 2486 (which anyone is of course free to
disagree with :-) is that it specifies a syntax for identifying
users with three important aspects:

  1) the NAI (usually) consists of two parts, username and realm,
     separated by "@"

  2) the "right" to use some realm is tied to obtaining a FQDN=20
     (that is, registering DNS name).

  3) the username part is allocated by the "owner" of the realm
     in whatever manner the owner wishes.

Item 2 means that "user@foo" is not a valid NAI (at least
as long as we don't have "foo" TLD).

Item 3 means that "[email-masked]" must be
interpreted as username "intermediary.com!user" in realm=20
"example.com" _except_ if the node processing it has specific
knowledge about how example.com realm allocates usernames=20
(typically example.com's AAA server would have this knowledge).

I know that syntaxes such as "ipass/[email-masked]" and=20
"user@foo" are commonly used, but IMHO they are not NAIs as=20
defined by RFC 2486. This, of course, does not prevent them from=20
working just fine in many protocols e.g. PPP CHAP or RADIUS=20
User-Name attribute, but this does not make them 2486-compliant...
(otherwise, "domain+user", "//domain/user" and even=20
"example.com@user" would be equally valid NAIs).

However, since especially the "intermediary selection"=20
seems to have many useful applications, I agree that 2486bis
should specify how it is done. The current 2486bis-00 tries
to do in a backward-compatible way that was already hinted
in RFC 2486 ("[email-masked]").

Another possibility would be "ipass/[email-masked]", but this
would mean a major change to RFC2486. First, it creates a new
namespace ("ipass" is not a valid realm name). Second, it breaks
compatibility with RFC 2486 because in effect it prevents the
use of usernames with "/" character.

I am not so sure what would be the advantage of creating=20
a non-FQDN namespace for "realms". Presumably, this namespace
has to be managed somehow, and obtaining a DNS name is IMHO
not an unreasonable requirement. Of course, IETF is not
a protocol police: if someone uses "user@foo" and it works
for him/her, we can't prevent that--but it's not NAI as
specified in RFC2486 but something else.

Best regards,
Pasi

> -----Original Message-----
> From: Blair T. Bullock
> Sent: Monday, March 22, 2004 10:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: rfc2486bis
>=20
>=20
> This raises some very good questions: =20
>=20
> In the roaming world, while the 'private' peering of RADIUS
> servers would allow for a non-FQDN to be used for the purposes
> of routing, i.e.  user@foo or even user@XZY, the common
> practice is to use a FQDN i.e.  [email-masked] or foo.bar.com or
> foo.org,etc.  However, there is no reasonable expectation that
> the FQDN be actually registered or owned by the home network
> and placed in DNS.  Since the peering is ambiguous and often
> private, I could just as well claim coke.com for my users or
> use some semblance of a FQDN, registered or not.  Obviously
> using a private IP would be bad, but using non DNS methods
> like [email-masked] is valid, right?  So why not a
> non-FQDN blair@myhome if the private RADIUS peering recognizes
> it.  Any thoughts on guidelines for this?
>=20
> Another question in regards to the current conversation...
>=20
> In a roaming application where there is a mediating network
> whose RADIUS exchange must be selected and transited in order
> to resolve private peering, is there any qualification which
> requires a FQDN?  We all know that the use of a prefix to
> select and exchange i.e.  IPASS/[email-masked] and or chained
> suffix to do so, i.e. [email-masked]@IPASS or
> [email-masked]@ipass.com is common practice... Can the '%' or
> '!' be used in combination with a non-FQDN as an alternative
> method for this NAI construction without applying an invalid
> syntax? i.e.  [email-masked] or [email-masked] rather
> than using a non-reserved delimiter such as '/' or 'chaining'
> the suffix which is described as illegal in the previous
> articles?  Again, use of non-FQDNs for the purposes of
> navigating private RADIUS exchanges is absolutely necessary,
> but the current (and past) NAI examples don't reflect these
> emerged models very well.
>=20
> And a question in regards to the latest NAI proposals...
>=20
> What is the basis for the 'position' swapping in the latest
> draft?  Changing ...  [email-masked] to
> "[email-masked]"
>=20
> ...breaks today's practice and would significantly impact the
> way in which networks peer today.  Is there a compelling
> reason for this or is it merely a proposal to once and for all
> formalize the inter-network NAI construction.  There are some
> significant issues with this approach, particularly in
> reflecting today's business models and practices of NAI
> construction.
>=20
> Thank you for your consideration.
>=20
> Best Regards,=20
>=20
> Blair

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Mar 2004 15:24:04 +0000
Date: Tue, 23 Mar 2004 07:32:04 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: Re: Private NAIs (Was: Re: rfc2486bis)

> So I think its pretty clear that the NAI realms should be registered
> via usual domain name procedures. However, the text in RFC 2486 leaves
> _some_ room for interpretation, as it first says "required" and then
> "should" and finally for no ownership it says "discouraged". Perhaps
> this text should be clarified in the bis version, e.g., made to a SHOULD
> or even a MUST. Or are you Blair arguing that it should be relaxed?

Overall, the intent of RFC 2486bis is clarification and
internationalization.  Anything beyond this is out of scope.

Relaxing the requirement on FQDN allocation would open up a can of worms
that is best left closed.  For example, Diameter can use DNS for service
location; if the NAI realms are "private" then this will break.  Also, allocation of
"private" realms would presumably require a description of which realms
are "private" in order to reserve them.  The IETF does not in general
have the authority to allocate FQDNs -- that's the purview of ICANN.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Mar 2004 12:01:51 +0000
Date: Tue, 23 Mar 2004 13:58:48 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Blair T. Bullock" <[email-masked]>
Cc: [email-masked]
Subject: Private NAIs (Was: Re: rfc2486bis)

Thanks Blair for your comments. I'll first respond to your
question about private vs. DNS registered NAI realms:

> In the roaming world, while the 'private' peering of RADIUS servers
> would allow for a non-FQDN to be used for the purposes of routing, i.e.
> user@foo or even user@XZY, the common practice is to use a FQDN i.e.

FYI: Allowing user@foo is a mistake in the -00 document and will be
corrected in -01. The cause of the mistake was a correction
that attempted to avoid the infinite loop in the original
BNF but opened up a little bit too much freedom :-(

> [email-masked] or foo.bar.com or foo.org,etc.  However, there is no
> reasonable expectation that the FQDN be actually registered or owned by
> the home network and placed in DNS.  Since the peering is ambiguous and
> often private, I could just as well claim coke.com for my users or use
> some semblance of a FQDN, registered or not.  Obviously using a private
> IP would be bad, but using non DNS methods like [email-masked] is
> valid, right?  So why not a non-FQDN blair@myhome if the private RADIUS
> peering recognizes it.   Any thoughts on guidelines for this?  

RFC 2486 does say that there is a requirement that the FQDNs
be owned by the home network:

    This document defines a new namespace that will need to be
    administered, namely the NAI realm namespace. In order to to avoid
    creating any new administrative procedures, administration of the NAI
    realm namespace will piggyback on the administration of the DNS
    namespace.

    NAI realm names are required to be unique and the rights to use a
    given NAI realm for roaming purposes are obtained coincident with
    acquiring the rights to use a particular fully qualified domain name
    (FQDN).  Those wishing to use an NAI realm name should first acquire
    the rights to use the corresponding FQDN. Using an NAI realm without
    ownership of the corresponding FQDN creates the possibility of
    conflict and therefore is to be discouraged.

So I think its pretty clear that the NAI realms should be registered
via usual domain name procedures. However, the text in RFC 2486 leaves
_some_ room for interpretation, as it first says "required" and then
"should" and finally for no ownership it says "discouraged". Perhaps
this text should be clarified in the bis version, e.g., made to a SHOULD
or even a MUST. Or are you Blair arguing that it should be relaxed?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Mar 2004 20:04:00 +0000
content-class: urn:content-classes:message
Subject: RE: rfc2486bis
Date: Mon, 22 Mar 2004 12:01:11 -0800
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked]
cc: [email-masked]

This raises some very good questions: =20

In the roaming world, while the 'private' peering of RADIUS servers
would allow for a non-FQDN to be used for the purposes of routing, i.e.
user@foo or even user@XZY, the common practice is to use a FQDN i.e.
[email-masked] or foo.bar.com or foo.org,etc.  However, there is no
reasonable expectation that the FQDN be actually registered or owned by
the home network and placed in DNS.  Since the peering is ambiguous and
often private, I could just as well claim coke.com for my users or use
some semblance of a FQDN, registered or not.  Obviously using a private
IP would be bad, but using non DNS methods like [email-masked] is
valid, right?  So why not a non-FQDN blair@myhome if the private RADIUS
peering recognizes it.   Any thoughts on guidelines for this? =20

Another question in regards to the current conversation...

In a roaming application where there is a mediating network whose RADIUS
exchange must be selected and transited in order to resolve private
peering, is there any qualification which requires a FQDN?  We all know
that the use of a prefix to select and exchange i.e. IPASS/[email-masked]
and or chained suffix to do so, i.e. [email-masked]@IPASS or
[email-masked]@ipass.com is common practice... Can the '%' or '!' be used
in combination with a non-FQDN as an alternative method for this NAI
construction without applying an invalid syntax? i.e.
[email-masked] or [email-masked] rather than using a
non-reserved delimiter such as '/' or 'chaining' the suffix which is
described as illegal in the previous articles?  Again, use of non-FQDNs
for the purposes of navigating private RADIUS exchanges is absolutely
necessary, but the current (and past) NAI examples don't reflect these
emerged models very well.

And a question in regards to the latest NAI proposals...

What is the basis for the 'position' swapping in the latest draft?
Changing ...
[email-masked] to=20
"[email-masked]"

...breaks today's practice and would significantly impact the way in
which networks peer today.  Is there a compelling reason for this or is
it merely a proposal to once and for all formalize the inter-network NAI
construction.  There are some significant issues with this approach,
particularly in reflecting today's business models and practices of NAI
construction.

Thank you for your consideration.

Best Regards,=20

Blair

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]=20
Sent: Friday, March 19, 2004 3:28 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: rfc2486bis

> I see that in the new draft the example "fred@foo" becomes now a valid

> NAI because the definition of the realm changed compard to the=20
> original RFC, but in naibis it is still in the invalid list - but that

> has to be changed I guess?
>=20
> Could there also be the following problem: "[email-masked]" was=20
> valid in the original RFC2486. Now how do I know whether the username=20
> is "eng!nancy", which is a valid username, or is the username "nancy"=20
> and homerealm "eng"? I believe it is better to use another symbol than

> "!" such as ":"?
>=20

I hope/assume that everyone knows/understands that we do not accept such
examples in RFCs. We want them to be of the form:

   [email-masked]
   [email-masked]

or some such.
See ID-NITs at http://www.ietf.org/ID-nits.html

Which says:

   o  Addresses used in examples should prefer use of fully qualified
      domain names to literal IP addresses, and prefer use of example
      fqdn's such as foo.example.com to real-world fqdn's
      See RFC 2606 for example domain names that can be used.

      There is also a range of IP addresses set aside for this purpose.
      These are 192.0.2.0/24 (see RFC 3330). Private addressess that
      would be used in the real world should be avoided in examples.

Bert=20
> regards,
>=20
> Stefaan
>=20
>=20
>=20
> Jari Arkko wrote:
> >=20
> > Bernard Aboba wrote:
> > >>1) examples in section 2.8: why is @howard.edu an invalid NAI? And

> > >>why has [email-masked] been removed from the list of
> valid NAIs
> > >>compared to RFC2486? I believe it is still valid, or should it be=20
> > >>put in the list of invalid NAIs?
> > >
> > >
> > > Good catch.  RFC 2486bis should not be introducing
> non-backward compatible
> > > changes.
> >=20
> > Yes. Thanks Stefaan for your comments!
> >=20
> > @howard.edu was actually listed as an illegal example
> > in RFC 2486; the introduction of the privacy feature
> > makes this now legal.
> >=20
> > [email-masked] is still legal. I removed it
> > as a part of providing a new set of examples, but
> > since there are questions about it, maybe I should
> > put it back in just to avoid people wondering whether
> > it has been made illegal.
> >=20
> > > 2) Would it not be better to define the nai in 2.1 as follows:
> > >
> > > nai =3D [realm "!"] ( <....> )
> > >
> > > with <....> the current nai defintion. This to make the
> explanation
> > > in section 2.7 more formal.
> >=20
> > Ok.
> >=20
> > > 3) typo: a quotation mark too much at the end in the nai
> definition
> > > in 2.1.
> >=20
> > Yes. Kalle Tammela also noticed this issue.
> >=20
> > I have corrected the above issues in
> >=20
> >    http://www.arkko.com/publications/nai/naibis.txt
> >=20
> > --Jari
>=20
> --
> to unsubscribe send a message to [email-masked] with=20
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 14:32:32 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: FW: Example domain names (Was: Re: rfc2486bis)
Date: Fri, 19 Mar 2004 15:32:05 +0100

Jari
Not the answer you wanted I guess... but.

Thanks,
Bert=20

-----Original Message-----
From: Patrik F=E4ltstr=F6m [mailto:[email-masked]]
Sent: vrijdag 19 maart 2004 14:55
To: Wijnen, Bert (Bert)
Subject: Re: Example domain names (Was: Re: rfc2486bis)

On 2004-03-19, at 13.38, Wijnen, Bert (Bert) wrote:

> Patrik,
> Do you know the answer to this one?

Many cc-TLD's do have their own list of registered domains. I know in=20
Sweden they use 2606 names + some in Swedish.

I.e. depends...

    paf

>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: vrijdag 19 maart 2004 12:41
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Example domain names (Was: Re: rfc2486bis)
>
>
> Wijnen, Bert (Bert) wrote:
>
>> I hope/assume that everyone knows/understands that we do not accept
>> such examples in RFCs. We want them to be of the form:
>> (snip)
>
> Yes. I actually did know that we need to convert the
> examples to the RFC 2606 names. (But this hasn't been
> done yet.)
>
> I do have one question though. Has there been any
> specific international domain names set aside for
> use is examples? RFC 2606 does not appear to talk
> about them.
>
> --Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 13:52:49 +0000
Date: Fri, 19 Mar 2004 15:49:43 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: rfc2486bis

[email-masked] wrote:

> In RFC2486, I see
> 
> 
>    realm       = realm "." label

Yes. Unfortunately, this rule has infinite
recursion, which is why there needs to be
some change. Not sure the current change
is right, but something has to be done.

> and in 2486bis, I read
> 
> 
>    realm       = [ realm "." ] ilabel
> 
> Now I was thinking that originaly, there must be an "." in the realm
> but in 2486bis, it is made optional making "foo" a valid realm. The
> addition of the  square brackets in 2486bis triggered my question.
> Should it be
> 
>   realm = 1*( realm "." ) ilabel

Sounds better, thanks!

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 11:58:58 +0000
Date: Fri, 19 Mar 2004 04:00:31 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: rfc2486bis

> I hope/assume that everyone knows/understands that we do not accept
> such examples in RFCs. We want them to be of the form:
>
>    [email-masked]
>    [email-masked]
>
> or some such.
> See ID-NITs at http://www.ietf.org/ID-nits.html
>
> Which says:
>
>    o  Addresses used in examples should prefer use of fully qualified
>       domain names to literal IP addresses, and prefer use of example
>       fqdn's such as foo.example.com to real-world fqdn's
>       See RFC 2606 for example domain names that can be used.
>
>       There is also a range of IP addresses set aside for this purpose.
>       These are 192.0.2.0/24 (see RFC 3330). Private addressess that
>       would be used in the real world should be avoided in examples.

Not only is it not legal as an example, it goes against the letter and
spirit of the original RFC.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 11:58:20 +0000
Date: Fri, 19 Mar 2004 13:55:34 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: rfc2486bis

Bernard Aboba wrote:
>>I see that in the new draft the example "fred@foo" becomes now a
>>valid NAI because the definition of the realm changed compard to the
>>original RFC, but in naibis it is still in the invalid list - but
>>that has to be changed I guess?
> 
> 
> I think this is a problem because "foo" is not a full qualified domain
> name.  This creates the need to reopen the namespace allocation mechanism
> in the IANA considerations section.  This is not something we want to
> reopen.

I agree with Bernard that we don't want to change the
namespace allocation.

But Stefaan, why do you think fred@foo should become
legal? I don't remember making any such change to the BNF
which would make it legal, unless "foo" is a TLD of course.
But I may have missed something. If so, tell me what...

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 11:51:09 +0000
Date: Fri, 19 Mar 2004 03:59:11 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: rfc2486bis

> I see that in the new draft the example "fred@foo" becomes now a
> valid NAI because the definition of the realm changed compard to the
> original RFC, but in naibis it is still in the invalid list - but
> that has to be changed I guess?

I think this is a problem because "foo" is not a full qualified domain
name.  This creates the need to reopen the namespace allocation mechanism
in the IANA considerations section.  This is not something we want to
reopen.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 11:43:55 +0000
Date: Fri, 19 Mar 2004 13:40:55 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: Example domain names (Was: Re: rfc2486bis)

Wijnen, Bert (Bert) wrote:

> I hope/assume that everyone knows/understands that we do not accept
> such examples in RFCs. We want them to be of the form:
> (snip) 

Yes. I actually did know that we need to convert the
examples to the RFC 2606 names. (But this hasn't been
done yet.)

I do have one question though. Has there been any
specific international domain names set aside for
use is examples? RFC 2606 does not appear to talk
about them.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 11:29:04 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: rfc2486bis
Date: Fri, 19 Mar 2004 12:28:24 +0100

> I see that in the new draft the example "fred@foo" becomes now a
> valid NAI because the definition of the realm changed compard to the
> original RFC, but in naibis it is still in the invalid list - but
> that has to be changed I guess?
> 
> Could there also be the following problem: "[email-masked]" was
> valid in the original RFC2486. Now how do I know whether the
> username is "eng!nancy", which is a valid username, or is the
> username "nancy" and homerealm "eng"? I believe it is better to use
> another symbol than "!" such as ":"?
> 

I hope/assume that everyone knows/understands that we do not accept
such examples in RFCs. We want them to be of the form:

   [email-masked]
   [email-masked]

or some such.
See ID-NITs at http://www.ietf.org/ID-nits.html

Which says:

   o  Addresses used in examples should prefer use of fully qualified
      domain names to literal IP addresses, and prefer use of example
      fqdn's such as foo.example.com to real-world fqdn's
      See RFC 2606 for example domain names that can be used.

      There is also a range of IP addresses set aside for this purpose.
      These are 192.0.2.0/24 (see RFC 3330). Private addressess that
      would be used in the real world should be avoided in examples.

Bert 
> regards,
> 
> Stefaan
> 
> 
> 
> Jari Arkko wrote:
> > 
> > Bernard Aboba wrote:
> > >>1) examples in section 2.8: why is @howard.edu an invalid NAI? And
> > >>why has [email-masked] been removed from the list of 
> valid NAIs
> > >>compared to RFC2486? I believe it is still valid, or should it be
> > >>put in the list of invalid NAIs?
> > >
> > >
> > > Good catch.  RFC 2486bis should not be introducing 
> non-backward compatible
> > > changes.
> > 
> > Yes. Thanks Stefaan for your comments!
> > 
> > @howard.edu was actually listed as an illegal example
> > in RFC 2486; the introduction of the privacy feature
> > makes this now legal.
> > 
> > [email-masked] is still legal. I removed it
> > as a part of providing a new set of examples, but
> > since there are questions about it, maybe I should
> > put it back in just to avoid people wondering whether
> > it has been made illegal.
> > 
> > > 2) Would it not be better to define the nai in 2.1 as follows:
> > >
> > > nai = [realm "!"] ( <....> )
> > >
> > > with <....> the current nai defintion. This to make the 
> explanation
> > > in section 2.7 more formal.
> > 
> > Ok.
> > 
> > > 3) typo: a quotation mark too much at the end in the nai 
> definition
> > > in 2.1.
> > 
> > Yes. Kalle Tammela also noticed this issue.
> > 
> > I have corrected the above issues in
> > 
> >    http://www.arkko.com/publications/nai/naibis.txt
> > 
> > --Jari
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 09:41:35 +0000
Date: Fri, 19 Mar 2004 10:41:17 +0100
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: rfc2486bis

Jari,

I see that in the new draft the example "fred@foo" becomes now a
valid NAI because the definition of the realm changed compard to the
original RFC, but in naibis it is still in the invalid list - but
that has to be changed I guess?

Could there also be the following problem: "[email-masked]" was
valid in the original RFC2486. Now how do I know whether the
username is "eng!nancy", which is a valid username, or is the
username "nancy" and homerealm "eng"? I believe it is better to use
another symbol than "!" such as ":"?

regards,

Stefaan

Jari Arkko wrote:
> 
> Bernard Aboba wrote:
> >>1) examples in section 2.8: why is @howard.edu an invalid NAI? And
> >>why has [email-masked] been removed from the list of valid NAIs
> >>compared to RFC2486? I believe it is still valid, or should it be
> >>put in the list of invalid NAIs?
> >
> >
> > Good catch.  RFC 2486bis should not be introducing non-backward compatible
> > changes.
> 
> Yes. Thanks Stefaan for your comments!
> 
> @howard.edu was actually listed as an illegal example
> in RFC 2486; the introduction of the privacy feature
> makes this now legal.
> 
> [email-masked] is still legal. I removed it
> as a part of providing a new set of examples, but
> since there are questions about it, maybe I should
> put it back in just to avoid people wondering whether
> it has been made illegal.
> 
> > 2) Would it not be better to define the nai in 2.1 as follows:
> >
> > nai = [realm "!"] ( <....> )
> >
> > with <....> the current nai defintion. This to make the explanation
> > in section 2.7 more formal.
> 
> Ok.
> 
> > 3) typo: a quotation mark too much at the end in the nai definition
> > in 2.1.
> 
> Yes. Kalle Tammela also noticed this issue.
> 
> I have corrected the above issues in
> 
>    http://www.arkko.com/publications/nai/naibis.txt
> 
> --Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Mar 2004 09:05:48 +0000
Date: Fri, 19 Mar 2004 10:05:03 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: [email-masked]
CC: [email-masked], Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: rfc2486bis

Jari, Stefaan and all,

Please see questions inline.

> @howard.edu was actually listed as an illegal example
> in RFC 2486; the introduction of the privacy feature
> makes this now legal.
>

1. I think it is more than the introduction of privacy feature that makes *only
realm* portion legal.

2. Even in the Wired world, there are possible cases where the NAS would like
to originate some AAA messages ( for ex: Accounting Off). Note that there won't
be NAI in these messages because they are not triggered by the user. The Radius
proxies can't forward to the *the correct Radius server*  because there is no
NAI in it.  Currently there are adhoc mechanisms to solve this issue. By
looking at the NAS-ID (or NAS-IP-Address), the Radius proxies find the
association between the Radius servers and will possibly mutilcast these kind
of messages. We can observe this is neither standard nor elegant solution.

I'm just wondering if this problem can be dealt in one of the two ways:

a.  Make NAI legal to carry only the realm portion also. ( Revised NAI can
allow this by adding some description)
b. Add Domain-Name attribute to the AAA message formats. ( doesn't look nice )

regards
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Mar 2004 18:48:22 +0000
Date: Thu, 18 Mar 2004 20:44:59 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: rfc2486bis

Bernard Aboba wrote:
>>1) examples in section 2.8: why is @howard.edu an invalid NAI? And
>>why has [email-masked] been removed from the list of valid NAIs
>>compared to RFC2486? I believe it is still valid, or should it be
>>put in the list of invalid NAIs?
> 
> 
> Good catch.  RFC 2486bis should not be introducing non-backward compatible
> changes.

Yes. Thanks Stefaan for your comments!

@howard.edu was actually listed as an illegal example
in RFC 2486; the introduction of the privacy feature
makes this now legal.

[email-masked] is still legal. I removed it
as a part of providing a new set of examples, but
since there are questions about it, maybe I should
put it back in just to avoid people wondering whether
it has been made illegal.

> 2) Would it not be better to define the nai in 2.1 as follows:
> 
> nai = [realm "!"] ( <....> )
> 
> with <....> the current nai defintion. This to make the explanation
> in section 2.7 more formal.

Ok.

> 3) typo: a quotation mark too much at the end in the nai definition
> in 2.1.

Yes. Kalle Tammela also noticed this issue.

I have corrected the above issues in

   http://www.arkko.com/publications/nai/naibis.txt

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Mar 2004 16:22:16 +0000
Date: Thu, 18 Mar 2004 08:23:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: rfc2486bis

> 1) examples in section 2.8: why is @howard.edu an invalid NAI? And
> why has [email-masked] been removed from the list of valid NAIs
> compared to RFC2486? I believe it is still valid, or should it be
> put in the list of invalid NAIs?

Good catch.  RFC 2486bis should not be introducing non-backward compatible
changes.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Mar 2004 15:52:24 +0000
Date: Thu, 18 Mar 2004 16:51:26 +0100
From: [email-masked]
To: [email-masked]
Subject: rfc2486bis

Hi,

I have a few small questions/comments on
draft-arkko-roamops-rfc2486bis-00:

1) examples in section 2.8: why is @howard.edu an invalid NAI? And
why has [email-masked] been removed from the list of valid NAIs
compared to RFC2486? I believe it is still valid, or should it be
put in the list of invalid NAIs?

2) Would it not be better to define the nai in 2.1 as follows:

nai = [realm "!"] ( <....> )

with <....> the current nai defintion. This to make the explanation
in section 2.7 more formal.

3) typo: a quotation mark too much at the end in the nai definition
in 2.1.

regards,

Stefaan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Mar 2004 05:42:05 +0000
Date: Wed, 17 Mar 2004 14:45:21 +0900
From: Mayumi Yanagiya <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT charter for comment - Take 7

> In order to ensure backward compatibility with RADIUS as well as
> Diameter, the following restrictions are imposed on extensions considered
> by the RADIUSEXT WG:
> 
> - All work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
> - All work MUST be compatible with equivalent facilities in Diameter.
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> - New attributes which contain sub-attributes must use only one level of
>   nesting, and be compatible with the construction used for VSAs in RFC
>   2865.
> - The RADIUS maximum packet size (4K) will not be increased.

  The 3rd restriction and the last one are same.

Regards,

Mayumi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Mar 2004 20:19:25 +0000
Date: Tue, 16 Mar 2004 12:28:19 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT charter for comment - Take 7

RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-03-16

Chair(s):
David Nelson <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions
to the RADIUS protocol required to enable its use in applications
such as IP telephony and Local Area Network authentication, authorization
and accounting.

In order to ensure backward compatibility with RADIUS as well as
Diameter, the following restrictions are imposed on extensions considered
by the RADIUSEXT WG:

- All work MUST be backward compatible with existing RADIUS RFCs,
  including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All work MUST be compatible with equivalent facilities in Diameter.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- New attributes which contain sub-attributes must use only one level of
  nesting, and be compatible with the construction used for VSAs in RFC
  2865.
- The RADIUS maximum packet size (4K) will not be increased.

Work Items

The immediate goals of the RADIUSEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
  for design of RADIUS attributes, including discussion of the
  appropriate use of RADIUS SDO-Specific Attributes (SSAs).

- Revised NAI specification.  This document, known as "RFC 2486bis"
  will revise the NAI specification to provide more details on
  routing as well as handling internationalization.

- Pre-paid support.  Prepaid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony.  In order to enable support of pre-paid services in an
  interoperable way, the WG will provide definitions of the
  attributes required to support operator service models for
  pre-paid, as documented in liaison communications.  Support
  will be included for time, volume, and event oriented charging
  as well as support for limited differential charging.
  This document will be compatible with Diameter Credit Control.

- SIP support.  RADIUS is currently used for SIP authentication,
  authorization and accounting.  Standardization of these attributes
  will enable improved interoperability.

- LAN attributes.  New attributes have been proposed to enable use of
  RADIUS authentication, authorization and accounting in wired and
  wireless LANs.  Standardization of these attributes will enable
  improved interoperability.

- MIB update.  RFC 2618-2621 lack IPv6 compatiblity, and modest
  changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Jun 05  RADIUS design guidelines submitted as a Proposed Standard RFC.
Jun 05  RFC 2486bis submitted as a Proposed Standard.
Dec 05  WLAN attributes submitted as a Proposed Standard RFC.
Dec 05  LAN attributes submitted as a Proposed Standard RFC.
Dec 05  SIP authentication draft submitted as a Proposed Standard RFC.
Dec 05  Prepaid draft submitted as a Proposed Standard RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
  demonstrated to be available to guarantee a high probability of
  success.  This includes recruitment of a core of editors and
  reviewers with significant IETF experience and demonstrated time
  commitment.

* All drafts will need to undergo review prior to acceptance as WG work
  items, which includes demonstration that the drafts are backward
  compatible with RADIUS RFCs and are compatible with equivalent
  facilities in Diameter.

* The WG will utilize an issue tracking system.

* XML to RFC will be used in production of documents.  This enables
  production of HTML and text files from a single source file as
  well as automated production of difference files.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Mar 2004 18:26:55 +0000
Date: Tue, 16 Mar 2004 13:26:04 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: RADEXT charter for comment...

Since I have been complaining about having come trouble understanding the 
meaning of some parts of the proposed charter, It seems I ought to propose 
wording that I think is clearer.  Of course, this reflects what I think it 
"should" mean, which may not be the same as other peoples interpretations.

In particular, I want to clarify one item in the constraint list, and one goal.

- New attributes which contain sub-attributes must use only one level on 
nesting, in parallel with the construction used for VSAs in RFC 2865.

-Pre-paid support.  Prepaid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony.  In order to enable support of pre-paid services in an
  interoperable way, the WG will provide definitions of the
  attributes required to support the operator service models for
  pre-paid, including time, volume, and event oriented charging.
  This work will include support for limited differential charging.

Yours,
Joel M. Halpern

At 08:31 AM 3/11/2004 -0800, Bernard Aboba wrote:
>In order to ensure backward compatibility with RADIUS as well as the
>Diameter, the following restrictions are imposed on extensions considered
>by the RADIUSEXT WG:
>
>...
>- Sub-attributes MUST be utilized only in a manner compatible with RFC
>   2865.
>...
>
>Work Items
>
>...
>- Pre-paid support.  Pre-paid services are contemplated in a number
>   of potential applications, including wireless LAN access and IP
>   telephony. In order to enable support of pre-paid services in an
>   interoperable way, the WG will initially focus on a BCP describing
>   "simple prepaid" which utilizes existing RADIUS attributes.
>
>...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 18:47:21 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: [email-masked]
Subject: Invited papers for CCCT04
Date: Fri, 12 Mar 2004 12:46:28 -0600

Hi All,

I am planning on organizing an invited paper session on 
"AAA and secure access for mobile and fixed users" for the CCCT04 conference
	http://www.iiisci.org/ccct2004/WebSite/Default.asp

I think the session will benefit greatly from a paper on work that is
being done on the extensions of RADIUS. We are however not necessarily
restricted by the RADEXT charter :)
Since this is an invited session the deadlines for abstracts are relaxed a bit, 
but the final deadlines still apply.
Please let me know if you are interested and then we can discuss details. 

Thank you and Regards,

Madjid Nakhjiri
Principal Staff Research Engineer
Motorola Labs

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 18:16:20 +0000
Date: Fri, 12 Mar 2004 10:25:17 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: RADEXT charter for comment...

Yes, I think it's in scope.

On Fri, 12 Mar 2004, Adrangi, Farid wrote:

> I did not see any response to your question.  The draft falls into LAN
> attribute category, so it should in the scope.
> BR,
> Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 18:11:56 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 20:08:02 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Avi,

> I agree that this should be done as seperate documents and I dont mind
> working on them.
>=20
> A question though, can someone please demonstrate a need for=20
> this work?

For the Radius WLAN work?
=20
> And finally, wouldnt NASREQ automatically handle the WLAN=20
> RADIUS attributes?

It all depends on what is defined in the WLAN Radius extension
draft. =20

Anyhow, 3GPP has already specified NASREQ for RADIUS & Diameter
WLAN interworking. Making sure we don't break anything when
we extend it is an important consideration, IMO.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 16:42:13 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 18:41:46 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

> I and others have previously agreed to review these documents
> and provide Diameter guidance (if needed). So I don't think
> lack of Diameter understanding should be a problem in developing
> the WLAN documents. If there's any problem in developing these
> documents, it may be agreement on exactly what information
> needs to be carried, but that's another issue...

I can also lend guidence and general review as well.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 16:33:13 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 11:32:54 -0500
From: "Nelson, David" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff writes...

> Yes, but how does changing the sub-Type field from 1 byte to 14 bits
and
> adding a couple of flags not require a code change?  Am I missing
> something obvious?

I think that you are right, Barney.  Adding these features would impact
the parsing code, somewhere, somehow.

I'd like to suggest an alternate way to introduce the Mandatory bit
feature in a RADIUS extension.  We could define a new attribute, called
the Mandatory attribute.  This attribute could be used to "flag" the
other attributes in a RADIUS datagram that are considered mandatory.
This could be done in one of two ways.  The Mandatory attribute could
share a common Tag with the attributes considered mandatory, or it could
include in the data portion of the attribute a list of all the attribute
type codes considered mandatory.

I think this approach was briefly considered in the early pre AAA WG
days, when proposals for extending and "fixing" RADIUS were first being
debated.  While this approach is far less elegant than the Mandatory
bit, it had the advantage of not changing the attribute AVP header
format.

Of course, any logic to implement the mandatory nature of any attribute
will require new code in RADIUS implementations, since this is a
policy-level behavioral issue.  I don't think there is any way to add
this feature to a NAS solely in a data dictionary driven fashion, at
least without some initial code changes to provide that support.  But
that is true of any new attribute with new semantics, at least in RADIUS
client implementations, so there is fine line to this "no code changes"
debate.  I think we could say "no code changes to the attribute parser",
and that would support the requirement to preserve existing data
dictionary driven implementations.

Adding support for new semantics, for example an attribute specifying
some QoS parameter, is obviously going to require new code somewhere in
the NAS.  Whether you consider that "enforcement" code part of the
RADIUS implementation is probably a matter of your particular design
decisions and code modularity structure.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 16:29:30 +0000
Date: Fri, 12 Mar 2004 18:26:54 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT charter for comment...

Bernard wrote:

> In the interest of focus, I think it would be ok to have a separate
> Diameter document.  Is there a volunteer to write that document?

I don't think focus should override the technically right way
to do things, particularly when...

Avi wrote:

> And finally, wouldnt NASREQ automatically handle the WLAN RADIUS attributes?

Right. It does. At least for 99.9% of the cases. The remaining
0.1% is designing something in RADIUS which already exists
in some other form in Diameter, and making the translation
difficult.

So I think that one document leads to exactly one way to
do things, one set of information, and less industry
fragmentation.

I and others have previously agreed to review these documents
and provide Diameter guidance (if needed). So I don't think
lack of Diameter understanding should be a problem in developing
the WLAN documents. If there's any problem in developing these
documents, it may be agreement on exactly what information
needs to be carried, but that's another issue...

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 16:29:15 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 08:28:37 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

I did not see any response to your question.  The draft falls into LAN
attribute category, so it should in the scope.
BR,
Farid

>=20
> Another question: Is the draft=20
> draft-lior-radius-redirection-00 also in the
> scope of the charter? Prepaid services can make use of it,=20
> but there are
> more applications. Or is this something that can be done=20
> after the initial
> work on "simple prepaid" has been completed?
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 16:06:51 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba ' <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 11:06:22 -0500

I agree that this should be done as seperate documents and I dont mind
working on them.

A question though, can someone please demonstrate a need for this work?

And finally, wouldnt NASREQ automatically handle the WLAN RADIUS attributes?

-----Original Message-----
From: Bernard Aboba
To: [email-masked]
Cc: [email-masked]
Sent: 3/12/04 10:59 AM
Subject: RE: RADEXT charter for comment...

> I assume this covers the request from the GSMA about the WLAN roaming.
> Do you think this can be covered in the same document as the other
> LAN attributes?  There were several aspects about WLAN roaming,
> and I am not sure that these all could be handled in one document.

We could have a separate document for WLAN and LAN.

> Also, on this topic, it seems that this would have quite a bit of
relevance
> to Diameter as well, so I would like to propose that we would consider
> the impact of WLAN roaming in both RADIUS & Diameter in a single
document.

In the interest of focus, I think it would be ok to have a separate
Diameter document.  Is there a volunteer to write that document?

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 15:58:40 +0000
From: Avi Lior <[email-masked]>
To: 'Korhonen Jouni ' <[email-masked]>,  "'Adrangi, Farid '" <[email-masked]>,  "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>,  "[email-masked] '" <[email-masked]>,  "[email-masked] '" <[email-masked]>,  "[email-masked] '" <[email-masked]>
Subject: RE: RADIUSExt BoF minutes
Date: Fri, 12 Mar 2004 10:58:09 -0500

Review of prepaid would be great.  

I have received some comments and am working on version 4.

I am going to be posting version 4 in about two weeks so please wait for
that. 

-----Original Message-----
From: Korhonen Jouni
To: Adrangi, Farid; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Sent: 3/12/04 4:42 AM
Subject: RE: RADIUSExt BoF minutes

HI,

I can volunteer reviewing the LAN & Prepaid drafts - if reviewers are
still needed.

br,
	Jouni

-- 
Jouni Korhonen - Senior Researcher
Emerging Technologies and Innovations
TeliaSonera Finland

> -----Original Message-----
> From: Adrangi, Farid [mailto:[email-masked]] 
> Sent: 11. maaliskuuta 2004 10:23
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RADIUSExt BoF minutes
> 
> Hello everyone,
> For the folks who weren't able to attend the BoF, attached please find
> the minutes.   Please let us know if you have any questions.
> BR,
> Farid
> 

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 15:50:36 +0000
Date: Fri, 12 Mar 2004 07:59:50 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: RADEXT charter for comment...

> I assume this covers the request from the GSMA about the WLAN roaming.
> Do you think this can be covered in the same document as the other
> LAN attributes?  There were several aspects about WLAN roaming,
> and I am not sure that these all could be handled in one document.

We could have a separate document for WLAN and LAN.

> Also, on this topic, it seems that this would have quite a bit of relevance
> to Diameter as well, so I would like to propose that we would consider
> the impact of WLAN roaming in both RADIUS & Diameter in a single document.

In the interest of focus, I think it would be ok to have a separate
Diameter document.  Is there a volunteer to write that document?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 15:04:02 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 10:02:45 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba writes...

> Actually, I proposed a 14-bit *type* field; the length field is still
8
> bits, although I suppose that could be extended as well.

Yes.  That's what I get for posting late in the evening.  :-) I meant
the type field.  As you correctly observed, changing the length of any
of the fixed-length attribute header fields has the same effect.

Now that my brain is more fully engaged, I wonder how important it would
be to have an expanded sub-attribute address space (type code) in an
SSA, where each SDO, by means of its unique OUI, has a separate block of
attribute type codes?  If anyone is seriously suggesting that any single
SDO would be proposing more than 255 new SSA sub-attributes for RADIUS,
I'd want to look at that assertion very closely. =20

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 09:42:53 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUSExt BoF minutes
Date: Fri, 12 Mar 2004 11:42:11 +0200
From: "Korhonen Jouni" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

HI,

I can volunteer reviewing the LAN & Prepaid drafts - if reviewers are
still needed.

br,
	Jouni

--=20
Jouni Korhonen - Senior Researcher
Emerging Technologies and Innovations
TeliaSonera Finland

=20

> -----Original Message-----
> From: Adrangi, Farid [mailto:[email-masked]]=20
> Sent: 11. maaliskuuta 2004 10:23
> To: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]
> Subject: RADIUSExt BoF minutes
>=20
> Hello everyone,
> For the folks who weren't able to attend the BoF, attached please find
> the minutes.   Please let us know if you have any questions.
> BR,
> Farid
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 08:51:37 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 10:50:41 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Jari,

> > I assume this covers the request from the GSMA about the WLAN =
roaming.
> > Do you think this can be covered in the same document as the other
> > LAN attributes?  There were several aspects about WLAN roaming,
> > and I am not sure that these all could be handled in one document. =20
>=20
> I think the charter should say WLAN roaming attributes, but
> when developing the eventual RFCs, we should be prepared to do
> a couple, organized logically.

That sounds reasonable.
=20
> > Also, on this topic, it seems that this would have quite a bit of =
relevance
> > to Diameter as well, so I would like to propose that we would =
consider
> > the impact of WLAN roaming in both RADIUS & Diameter in a single =
document.
>=20
> Yes. There's simply no technical reason to make this document(s)
> RADIUS specific.

Good.

thanks,
John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 08:31:21 +0000
Date: Fri, 12 Mar 2004 09:30:44 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT charter for comment...

> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
>

I volunteer to review all the documents except SIP related drafts.

-Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 08:05:06 +0000
Date: Fri, 12 Mar 2004 10:02:33 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RADEXT charter for comment...

[email-masked] wrote:
> Bernard,
> 
> A question for you:
> 
> 
>>- LAN attributes.  New attributes have been proposed to enable use of
>>  RADIUS authentication, authorization and accounting in wired and
>>   wireless LANs.  Standardization of these attributes will enable
>>  improved interoperability.
> 
> 
> I assume this covers the request from the GSMA about the WLAN roaming.
> Do you think this can be covered in the same document as the other
> LAN attributes?  There were several aspects about WLAN roaming,
> and I am not sure that these all could be handled in one document.  

I think the charter should say WLAN roaming attributes, but
when developing the eventual RFCs, we should be prepared to do
a couple, organized logically.

> Also, on this topic, it seems that this would have quite a bit of relevance
> to Diameter as well, so I would like to propose that we would consider
> the impact of WLAN roaming in both RADIUS & Diameter in a single document.

Yes. There's simply no technical reason to make this document(s)
RADIUS specific.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 07:23:30 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Fri, 12 Mar 2004 09:22:31 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

A question for you:

> - LAN attributes.  New attributes have been proposed to enable use of
>   RADIUS authentication, authorization and accounting in wired and
>    wireless LANs.  Standardization of these attributes will enable
>   improved interoperability.

I assume this covers the request from the GSMA about the WLAN roaming.
Do you think this can be covered in the same document as the other
LAN attributes?  There were several aspects about WLAN roaming,
and I am not sure that these all could be handled in one document. =20

Also, on this topic, it seems that this would have quite a bit of =
relevance
to Diameter as well, so I would like to propose that we would consider
the impact of WLAN roaming in both RADIUS & Diameter in a single =
document.

thanks,
John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 05:21:25 +0000
Date: Fri, 12 Mar 2004 00:20:49 -0500
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: RADEXT charter for comment...

On Thu, Mar 11, 2004 at 07:15:15PM -0800, Bernard Aboba wrote:
> 
> In theory an existing RADIUS implementation supporting VSAs already needs
> to be prepared to support sub-attributes within VSAs, since RFC 2865
> says that is a possibility.  Therefore if an implementation already
> supported that (optional) feature of RFC 2865, no software update should
> be required (assuming that the sub-attributes are comprised of existing
> RADIUS data types).

Yes, but how does changing the sub-Type field from 1 byte to 14 bits and
adding a couple of flags not require a code change?  Am I missing
something obvious?

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 03:56:45 +0000
Date: Thu, 11 Mar 2004 20:04:03 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: RADEXT charter for comment...

> Primarily the M and R bits, but also the 14-bit length field.

Actually, I proposed a 14-bit *type* field; the length field is still 8
bits, although I suppose that could be extended as well.

> Here's why I think the extended length field is significant. While *any*
> octet string that fits within the length impositions of a VSA could be
> the "vendor data" part, the suggested format in RFC 2865 indicates that
> the existing RADIUS attribute structure is [re]used.  For VSA encodings
> that follow this recommendation, existing RADIUS implementations only
> need detect the VSA, and then "recursively" call the RADIUS attribute
> parser code to extract the vendor AVPs from within the VSA.

While I didn't propose changing the length field, your argument probably
remains valid given that the length field is now located in a different
place.

> The suggested format for SSA would defeat this "recursive AVP parsing"
> trick.  Is this an important tradeoff?  I'm not sure...  Does any one
> use this technique for parsing VSA sub-attributes?

Good question.  I think this may be an argument for allocating a special
type code for "SDO-specific attributes".  We could then define a special
format for that attribute and not have to worry about backward
compatibility issues.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 03:41:22 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Thu, 11 Mar 2004 22:36:49 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> > I think the inclusion of the two bit fields (M, R) and a 14-bit
vendor
> > type field would be a good idea.  If we are to do this, I would
> > recommend using a different type code than 26, in aid of backward
> > compatibility.
>=20
> I suppose that the issue of backward compatiblity is the presence of
an
> 'M' bit, correct? VSAs are other-wise always assumed optional and it
is
> probably not appropriate for something other than an SSA to carry such
a
> bit.
> Or is there some other issue too?

Primarily the M and R bits, but also the 14-bit length field.

Here's why I think the extended length field is significant. While *any*
octet string that fits within the length impositions of a VSA could be
the "vendor data" part, the suggested format in RFC 2865 indicates that
the existing RADIUS attribute structure is [re]used.  For VSA encodings
that follow this recommendation, existing RADIUS implementations only
need detect the VSA, and then "recursively" call the RADIUS attribute
parser code to extract the vendor AVPs from within the VSA. =20

This would allow the vendor sub-attributes to be entered into a data
dictionary, at least one that was segregated by OUI so as to resolve
otherwise duplicate type encodings.  This implementation method relies
on the length of the vendor sub-attribute fields (AVPs) matching the
lengths of the corresponding standard RADIUS attribute header fields. If
the "vendor data" part follows some other pattern, it would not possible
to build a generic VSA sub-attribute parser that would be data
dictionary driven. =20

The suggested format for SSA would defeat this "recursive AVP parsing"
trick.  Is this an important tradeoff?  I'm not sure...  Does any one
use this technique for parsing VSA sub-attributes?

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 03:05:53 +0000
Date: Thu, 11 Mar 2004 19:15:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: RADEXT charter for comment...

> I'm confused.  As someone who might conceivably be paid to extend
> RADIUS software I ought to applaud, but I thought there was a
> prohibition on requiring software update.  Did I miss something?

In theory an existing RADIUS implementation supporting VSAs already needs
to be prepared to support sub-attributes within VSAs, since RFC 2865
says that is a possibility.  Therefore if an implementation already
supported that (optional) feature of RFC 2865, no software update should
be required (assuming that the sub-attributes are comprised of existing
RADIUS data types).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Mar 2004 03:04:08 +0000
Date: Thu, 11 Mar 2004 19:13:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: RADEXT charter for comment...

> I think the inclusion of the two bit fields (M, R) and a 14-bit vendor
> type field would be a good idea.  If we are to do this, I would
> recommend using a different type code than 26, in aid of backward
> compatibility.

I suppose that the issue of backward compatiblity is the presence of an
'M' bit, correct? VSAs are other-wise always assumed optional and it is
probably not appropriate for something other than an SSA to carry such a bit.
Or is there some other issue too?

> I would also be interested in hearing the debate on
> whether this ought to be open to "Extended VSA" usage or ought to be
> limited to SSA usage.  I tend to prefer the latter.

I guess the answer depends on how great the need is for grouped
attributes.  Personally, I haven't found the case compelling so far, but
on the other hand, if done in this manner it doesn't run afoul of RFC
2865 either.

> On a related subject, I am not much in favor of the notion of using a
> Vendor ID or "0" to generally extend the RADIUS attribute space, within
> the existing VSA attribute, but would be interested to hear pros and
> cons of that approach.

I guess the "pro" is that we might kill two birds with one stone: put to
rest the arguments over support for sub-attributes, and potentially extend
the RADIUS attribute space.  Since VSAs can already contain sub-attributes
one could argue that such a proposal is backward compatible with RFC 2865,
at least if one leaves aside the 'M' bit proposal.

The con, is that if the goal is to make things easy to deploy, then it's a
lot simpler to use standard data types and add values to the dictionary.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 21:02:59 +0000
Date: Thu, 11 Mar 2004 16:01:54 -0500
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: RADEXT charter for comment...

On Thu, Mar 11, 2004 at 11:39:09AM -0800, Bernard Aboba wrote:
> 
> A 16-bit Vendor type field might make more sense; this is large enough
> that one might even be able to squeeze in a 'M'andatory bit, and a bit
> reserved for future use, as follows:

I'm confused.  As someone who might conceivably be paid to extend
RADIUS software I ought to applaud, but I thought there was a
prohibition on requiring software update.  Did I miss something?

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 19:39:35 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Thu, 11 Mar 2004 14:39:19 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba writes...

> On this subject, I think that a suggested SDO-Specific Attribute (SSA)
> format can do better than what is proposed in RFC 2865.  The suggested
VSA
> format in RFC 2865 only has a single octet Type field.  That is too
small:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Vendor type   | Vendor length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Agreed.

> A 16-bit Vendor type field might make more sense; this is large enough
> that one might even be able to squeeze in a 'M'andatory bit, and a bit
> reserved for future use, as follows:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           |M|R|      Vendor type
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Vendor Length |       Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think the inclusion of the two bit fields (M, R) and a 14-bit vendor
type field would be a good idea.  If we are to do this, I would
recommend using a different type code than 26, in aid of backward
compatibility.  I would also be interested in hearing the debate on
whether this ought to be open to "Extended VSA" usage or ought to be
limited to SSA usage.  I tend to prefer the latter.

On a related subject, I am not much in favor of the notion of using a
Vendor ID or "0" to generally extend the RADIUS attribute space, within
the existing VSA attribute, but would be interested to hear pros and
cons of that approach.

-- Dave

>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 19:33:13 +0000
Date: Thu, 11 Mar 2004 20:32:39 +0100
From: [email-masked]
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: RADEXT charter for comment...

> 
> - MIB update.  RFC 2618-2621 lack IPv6 compatiblity and modest
>   changes are required to address this issue.
> 

Would it be interesting to extend this item to include MIB updates to
support disconnect and CoA messages as well? 

Another question: Is the draft draft-lior-radius-redirection-00 also in the
scope of the charter? Prepaid services can make use of it, but there are
more applications. Or is this something that can be done after the initial
work on "simple prepaid" has been completed?

> 
> * This WG will not be chartered until sufficient resources can be
>   demonstrated to be available to guarantee a high probability of
>   success.  This includes recruitment of a core of editors and
>   reviewers with significant IETF experience and demonstrated time
>   commitment.
> 

I volunteer to review prepaid, LAN attributes, and MIB.

regards,

Stefaan

> * All drafts will need to undergo review prior to acceptance as WG work
>   items, which includes demonstration that the drafts are backward
>   compatible with RADIUS RFCs and are compatible with equivalent
>   facilities in Diameter.
> 
> * The WG will utilize an issue tracking system.
> 
> * XML to RFC will be used in production of documents.  This enables
>   production of HTML and text files from a single source file as
>   well as automated production of difference files.
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 19:29:56 +0000
Date: Thu, 11 Mar 2004 11:39:09 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: RADEXT charter for comment...

On this subject, I think that a suggested SDO-Specific Attribute (SSA)
format can do better than what is proposed in RFC 2865.  The suggested VSA
format in RFC 2865 only has a single octet Type field.  That is too small:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

A 16-bit Vendor type field might make more sense; this is large enough
that one might even be able to squeeze in a 'M'andatory bit, and a bit
reserved for future use, as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           |M|R|      Vendor type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor Length |       Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 19:22:54 +0000
Date: Thu, 11 Mar 2004 11:31:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
cc: [email-masked]
Subject: Re: RADEXT charter for comment...

There is a proposal on the table to utilize a vendor-Id of zero
within VSAs, to extend the IETF RADIUS attribute space.  From my reading
of RFC 2865, it would be legal to support one level of sub-attributes
within such an "extension".  Whether this is a good idea or not is another
question.

On Thu, 11 Mar 2004, Joel M. Halpern wrote:

> Yes, the limits for size and type must be followed.
> If we want this restriction to say that sub-attributes shall use VSAs with
> a specified vendor-ID, then we need to say that. (I hope not.)
> If we want this restriction to say that for consistency with the VSA usage
> in 2865, all sub-attributes shall be one level deep, we should say that.
> I think that the sentence as written does not say what we mean.
>
> Yours,
> Joel M. Halpern

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 18:39:01 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Thu, 11 Mar 2004 13:38:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Joel Halpern writes...

> If we want this restriction to say that sub-attributes shall use VSAs
with
> a specified vendor-ID, then we need to say that. (I hope not.)

I think that the notion is that sub-attributes may be encapsulated in
the VSA attribute or in a new, but similar, SDO-Specific Attribute
(SSA).  I interpret the formatting restrictions to be the same for
either VSA or SSA, with the difference that anyone can create VSAs, and
the format shown in RFC 2865 is a SHOULD, while only SDOs can create
SSAs, and the format shown in RFC 2865 (for VSAs) is a MUST.  Whether
the SSA shares the type code of 26 with VSA and is only distinguished by
the OUI value (belonging to an SDO), or has a distinct type code is, up
for debate.

> If we want this restriction to say that for consistency with the VSA
usage
> in 2865, all sub-attributes shall be one level deep, we should say
that.

I would very much like to say that.

> I think that the sentence as written does not say what we mean.

I guess that was the basis of my comment, seeking a clarification.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 18:30:50 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Thu, 11 Mar 2004 13:30:26 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Joel Halpern writes...

> It was not clear to me (and may not be clear to other readers in the
> future) that this line in the charter is intended to refer to the
> structure of vendor specific attributes.

Did you find any other reference to sub-attributes in RFC 2865?

> In fact, in looking at 2865 for a context for the line, the=20
> definition of VSAs was one part I assumed was not intended.

Why?

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 17:22:02 +0000
Date: Thu, 11 Mar 2004 12:21:13 -0500
To: Bernard Aboba <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: RADEXT charter for comment...
Cc: [email-masked]

Yes, the limits for size and type must be followed.
If we want this restriction to say that sub-attributes shall use VSAs with 
a specified vendor-ID, then we need to say that. (I hope not.)
If we want this restriction to say that for consistency with the VSA usage 
in 2865, all sub-attributes shall be one level deep, we should say that.
I think that the sentence as written does not say what we mean.

Yours,
Joel M. Halpern

At 09:12 AM 3/11/2004 -0800, Bernard Aboba wrote:
> > Looking again at 2865, I am not sure what it means to say that
> > Sub-attributes MUST be utilized only in a manner compatible with RFC
> > 2865.  Does this mean that that the base attribute must have a well defined
> > type, and a total length less than 256?  Or is there some other restriction
> > in 2865 that I have missed?
>
>The Type and Length fields need to be the same for all RADIUS attributes;
>in particular the length restriction permits attributes up to 253 octets.
>
>RFC 2865 explicitly permits grouping of attributes within the Vendor
>Specific (26) attribute.  Here's what Section 5.26 says:
>
>       Multiple subattributes MAY be encoded within a single Vendor-
>       Specific attribute, although they do not have to be.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 17:03:42 +0000
Date: Thu, 11 Mar 2004 12:03:24 -0500
To: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>,<[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: RADEXT charter for comment...

It was not clear to me (and may not be clear to other readers in the 
future) that this line in the charter is intended to refer to the structure 
of vendor specific attributes.  In fact, in looking at 2865 for a context 
for the line, the definition of VSAs was one part I assumed was not intended.

Yours,
Joel M. Halpern

At 11:53 AM 3/11/2004 -0500, Nelson, David wrote:
> > - Sub-attributes MUST be utilized only in a manner compatible with RFC
> >   2865.
>
>The relevant text from RFC 2865 is:
>
>       "It SHOULD be encoded as a sequence of vendor type / vendor length
>       / value fields, as follows.  The Attribute-Specific field is
>       dependent on the vendor's definition of that attribute.  An
>       example encoding of the Vendor-Specific attribute using this
>       method follows:
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Vendor-Id (cont)           | Vendor type   | Vendor length |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Attribute-Specific...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
>       Multiple subattributes MAY be encoded within a single Vendor-
>       Specific attribute, although they do not have to be."
>
>So the "SHOULD" (above) is being promoted to a "MUST" for work within
>the scope of RADEXT, correct?  Is it clear from this snippet of RFC 2865
>that the nesting of sub-attributes is only one layer deep?  That is my
>interpretation.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 17:03:16 +0000
Date: Thu, 11 Mar 2004 09:12:41 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
cc: [email-masked]
Subject: Re: RADEXT charter for comment...

> Looking again at 2865, I am not sure what it means to say that
> Sub-attributes MUST be utilized only in a manner compatible with RFC
> 2865.  Does this mean that that the base attribute must have a well defined
> type, and a total length less than 256?  Or is there some other restriction
> in 2865 that I have missed?

The Type and Length fields need to be the same for all RADIUS attributes;
in particular the length restriction permits attributes up to 253 octets.

RFC 2865 explicitly permits grouping of attributes within the Vendor
Specific (26) attribute.  Here's what Section 5.26 says:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 16:54:50 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT charter for comment...
Date: Thu, 11 Mar 2004 11:53:25 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba writes...

I think this version is moving us toward a reasonable consensus.  A few
comments are included, in-line.

Regards,
=20
Dave
=20
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as Local Area Network authentication authorization and
accounting.
>=20
> In order to ensure backward compatibility with RADIUS as well as the
> Diameter, the following restrictions are imposed on extensions
considered
> by the RADIUSEXT WG:
>=20
> - All work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2816-2820, 2865-2869, 3162, 3575, 3576, 3579, and
3580.
> - All work MUST be compatible with equivalent facilities in Diameter,
>   including the RADIUS/Diameter gateway specified in the Diameter
>   NASREQ specification.
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> - Sub-attributes MUST be utilized only in a manner compatible with RFC
>   2865.

The relevant text from RFC 2865 is:

      "It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be."

So the "SHOULD" (above) is being promoted to a "MUST" for work within
the scope of RADEXT, correct?  Is it clear from this snippet of RFC 2865
that the nesting of sub-attributes is only one layer deep?  That is my
interpretation.

> - The RADIUS maximum packet size (4K) will not be increased.

This last line is a duplicate.

> - No new RADIUS security mechanisms will be defined.
>=20
> Work Items
>=20
> The immediate goals of the RADIUSEXT working group are to address the
> following issues:
>=20
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs).

Should this not be the first deliverable, given that it may serve as a
"quality control guideline" for other WG work items?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 16:21:35 +0000
Date: Thu, 11 Mar 2004 08:31:01 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT charter for comment...

Here's another rev of the RADEXT WG charter.  Comments?

------------------------------------------------
RADIUS Extensions Working Group (RADEXT) Charter
Last Modified: 2004-03-09

Chair(s):
David Nelson <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions
to the RADIUS protocol required to enable its use in applications
such as Local Area Network authentication authorization and accounting.

In order to ensure backward compatibility with RADIUS as well as the
Diameter, the following restrictions are imposed on extensions considered
by the RADIUSEXT WG:

- All work MUST be backward compatible with existing RADIUS RFCs,
  including RFCs 2816-2820, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All work MUST be compatible with equivalent facilities in Diameter,
  including the RADIUS/Diameter gateway specified in the Diameter
  NASREQ specification.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- Sub-attributes MUST be utilized only in a manner compatible with RFC
  2865.
- The RADIUS maximum packet size (4K) will not be increased.
- No new RADIUS security mechanisms will be defined.

Work Items

The immediate goals of the RADIUSEXT working group are to address the
following issues:

- RADIUS design guidelines.  This document will provide guidelines
  for design of RADIUS attributes, including discussion of the
  appropriate use of RADIUS SDO-Specific Attributes (SSAs).

- Revised NAI specification.  This document, known as "RFC 2486bis"
  will revise the NAI specification to provide more details on
  routing as well as handling internationalization.

- Pre-paid support.  Pre-paid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony. In order to enable support of pre-paid services in an
  interoperable way, the WG will initially focus on a BCP describing
  "simple prepaid" which utilizes existing RADIUS attributes.

- SIP support.  RADIUS is currently used for SIP authentication,
  authorization and accounting.  Standardization of these attributes
  will enable improved interoperability.

- LAN attributes.  New attributes have been proposed to enable use of
  RADIUS authentication, authorization and accounting in wired and
   wireless LANs.  Standardization of these attributes will enable
  improved interoperability.

- MIB update.  RFC 2618-2621 lack IPv6 compatiblity and modest
  changes are required to address this issue.

Goals and Milestones:

Dec 04  Updated RADIUS MIBs submitted for publication.
Jun 05  RFC 2486bis submitted as a Proposed Standard.
Jun 05  RADIUS design guidelines submitted as an Informational RFC.
Jun 05  SIP authentication draft submitted as a Proposed Standard RFC.
Jun 06  RADIUS attributes for LANs submitted as a Proposed Standard RFC.
Jun 06  RADIUS pre-paid suport submitted as an Informational RFC.

Quality Control Plan

In order to ensure quality of work:

* This WG will not be chartered until sufficient resources can be
  demonstrated to be available to guarantee a high probability of
  success.  This includes recruitment of a core of editors and
  reviewers with significant IETF experience and demonstrated time
  commitment.

* All drafts will need to undergo review prior to acceptance as WG work
  items, which includes demonstration that the drafts are backward
  compatible with RADIUS RFCs and are compatible with equivalent
  facilities in Diameter.

* The WG will utilize an issue tracking system.

* XML to RFC will be used in production of documents.  This enables
  production of HTML and text files from a single source file as
  well as automated production of difference files.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 16:06:42 +0000
Date: Thu, 11 Mar 2004 08:15:50 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for review:  Diameter NASREQ specification

The Diameter NASREQ specification is in the last phases of review prior to
publication as an IETF Proposed Standard.  This specification is quite
important to the evolution of both Diameter and RADIUS because it contains
the specification of the RADIUS/Diameter gateway.

The RADIUS/Diameter gateway is designed to translate RADIUS attributes to
Diameter AVPs and vice versa, as well as handling translation between
RADIUS and Diameter commands.

In effect, the RADIUS/Diameter gateway specification defines what it means
for a RADIUS "extension" to be backward compatible with Diameter;  if the
gateway can handle it, it's compatible; if it cannot be handled, that
extension is not compatible.

It is therefore quite important that this specification be carefully
reviewed prior to publication.

The specification is available at:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-14.txt

Please send comments to the AAA WG mailing list ([email-masked]) using
the Issues format described on the Issues list:

http://www.drizzle.com/~aboba/AAA/issues.html

Please send comments by the Friday, March 19, 2004.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 14:32:12 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Bar BoF minutes; Reviewer for RADIUSEXT SIP drafts
Date: Thu, 11 Mar 2004 15:31:34 +0100

Harry Behrens of Snom (a German SIP vendor) volunteered to review SIP drafts
in RADIUSEXT. 

Wolfgang

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 09:59:18 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUSExt BoF minutes
Date: Thu, 11 Mar 2004 11:58:46 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

In order to avoid any future confusion, it would be useful to mention =
that this was an un-official or Bar-BOF.

I would be interested to particpate in the work and review the documents =
related to LAN attributes and SIP.

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Adrangi, Farid
> Sent: 11 March, 2004 10:23 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]
> Subject: RADIUSExt BoF minutes
>=20
>=20
> Hello everyone,
> For the folks who weren't able to attend the BoF, attached please find
> the minutes.   Please let us know if you have any questions.
> BR,
> Farid
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Mar 2004 08:24:12 +0000
content-class: urn:content-classes:message
Subject: RADIUSExt BoF minutes
Date: Thu, 11 Mar 2004 00:23:11 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C40742.171AA682
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello everyone,
For the folks who weren't able to attend the BoF, attached please find
the minutes.   Please let us know if you have any questions.
BR,
Farid

------_=_NextPart_001_01C40742.171AA682
Content-Type: application/msword;
	name="ietf59-radius-bof-minutes.doc"
Content-Transfer-Encoding: base64
Content-Description: ietf59-radius-bof-minutes.doc
Content-Disposition: attachment;
	filename="ietf59-radius-bof-minutes.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA
EAAAQQAAAAEAAAD+////AAAAAEAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////AQAAAP7///8D
AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C40742.171AA682--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 02 Mar 2004 01:39:14 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Adrangi, Farid'" <[email-masked]>, 'Parviz Yegani' <[email-masked]>
Subject: RADIUS Bar BOF at Emerald Room
Date: Mon, 1 Mar 2004 20:39:09 -0500 

Folks:

Time:  Tuesday at 18:30
Location:  The Emerald Room.  Located on the second floor.
We may be in the room or in the foyer just outside the room.  (This is not a
bar, but we can go to a bar afterwards)

Items for discussion:
Charter and what is going on.  How do we move forward?
Some of the authors of current drafts will be there.  It would be nice to
have each author briefly update us on their current work.  We should give
people the option to ask questions.

I would think this will last for about 1:30  hours.

Avi

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2004 5:11 PM
To: [email-masked]
Subject: Who is planning to be in Korea?

We would like to know who is planning to be in Korea.

Perhaps we can get together one night for some beer.  

Avi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 02 Mar 2004 01:34:48 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Adrangi, Farid'" <[email-masked]>, 'Parviz Yegani' <[email-masked]>
Subject: 
Date: Mon, 1 Mar 2004 20:34:17 -0500 

Folks:

Time:  Tuesday at 18:30
Location:  The Emerald Room.  Located on the second floor.
We may be in the room or in the foyer just outside the room.  (This is not a
bar, but we can go to a bar afterwards)

Items for discussion:
Charter and what is going on.  How do we move forward?
Some of the authors of current drafts will be there.  It would be nice to
have each author briefly update us on their current work.  We should give
people the option to ask questions.

I would think this will last for about 1:30  hours.

Avi

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2004 5:11 PM
To: [email-masked]
Subject: Who is planning to be in Korea?

We would like to know who is planning to be in Korea.

Perhaps we can get together one night for some beer.  

Avi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>