Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 21:07:34 +0000 Message-ID: <6D35646A8219B2408FBB811911EF3CDD03C379FE@zrc2c010.us.nortel.com> From: "Kuntal Chowdhury" To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org Subject: RE: RE: AAAEXT charter, Take 1 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 20:54:15 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 23:52:35 +0300 Message-ID: Thread-Topic: RE: AAAEXT charter, Take 1 Thread-Index: AcQXXumyUREN4xXCQEqsQBXbixdDxwAAutBA From: To: Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 20:28:10 +0000 Message-ID: <6D35646A8219B2408FBB811911EF3CDD03C378A9@zrc2c010.us.nortel.com> From: "Kuntal Chowdhury" To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org 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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Wednesday, March 31, 2004 2:02 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: radiusext@ops.ietf.org >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 >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 20:04:19 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 23:02:09 +0300 Message-ID: Thread-Topic: RE: AAAEXT charter, Take 1 Thread-Index: AcQXVR+iUBmpRWoDSue5dH/qE6TTWAABc5sA From: To: Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 19:44:01 +0000 Message-ID: <6D35646A8219B2408FBB811911EF3CDD03C37760@zrc2c010.us.nortel.com> From: "Kuntal Chowdhury" To: Greg Weber Cc: radiusext@ops.ietf.org 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:gdweber@cisco.com] >Sent: Wednesday, March 31, 2004 1:28 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: john.loughney@nokia.com; radiusext@ops.ietf.org >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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> >Sent: Wednesday, March 31, 2004 11:51 AM >> >To: avi@bridgewatersystems.com; aboba@internaut.com; >> >radiusext@ops.ietf.org >> >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 >> >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >> >a single line as the message text body. >> >archive: >> > >> >> -- >> to unsubscribe send a message to radiusext-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 19:29:24 +0000 From: Greg Weber Message-Id: <200403311927.OAA15381@cisco.com> Subject: Re: AAAEXT charter, Take 1 To: chowdury@nortelnetworks.com (Kuntal Chowdhury) Date: Wed, 31 Mar 2004 14:27:52 -0500 (EST) Cc: john.loughney@nokia.com, radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > 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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >Sent: Wednesday, March 31, 2004 11:51 AM > >To: avi@bridgewatersystems.com; aboba@internaut.com; > >radiusext@ops.ietf.org > >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 > >radiusext-request@ops.ietf.org with the word 'unsubscribe' in > >a single line as the message text body. > >archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 19:19:37 +0000 Message-ID: <6D35646A8219B2408FBB811911EF3CDD03C37691@zrc2c010.us.nortel.com> From: "Kuntal Chowdhury" To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org 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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Wednesday, March 31, 2004 11:51 AM >To: avi@bridgewatersystems.com; aboba@internaut.com; >radiusext@ops.ietf.org >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 >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 19:10:30 +0000 Message-Id: <5.2.1.1.2.20040331135957.04342730@getmail.mitton.com> Date: Wed, 31 Mar 2004 14:04:09 -0500 To: Radius Extensions From: David Mitton Subject: Re: AAAEXT charter, Take 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed On 3/31/2004 07:58 AM -0800, Richard Perlman wrote: >On 3/31/04 07:51, "Bernard Aboba" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:57:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 20:53:21 +0300 Message-ID: Thread-Topic: AAAEXT charter, Take 1 Thread-Index: AcQXP1x6+PpjriL2Q1SbOtmNJN/cwAAAKQ3QAAI8qqA= From: To: , , , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:52:45 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 20:51:25 +0300 Message-ID: Thread-Topic: AAAEXT charter, Take 1 Thread-Index: AcQXQ/TQRNEix1l7TRGwET99yni2OgABLKPQ From: To: , , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:33:18 +0000 Message-ID: <406B001F.6050301@piuha.net> Date: Wed, 31 Mar 2004 20:30:07 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: AAAEXT charter, Take 1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:24:11 +0000 Message-ID: <406AFE08.4030708@piuha.net> Date: Wed, 31 Mar 2004 20:21:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: MORAND Lionel FTRD/DAC/ISS Cc: Radius Extensions Subject: Re: RE : AAAEXT charter, Take 1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:14:53 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: RE: AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 12:13:59 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aboba@internaut.com] > Sent: Wednesday, March 31, 2004 10:52 AM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 17:02:52 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 19:01:41 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026D12475@ftrdmel2.rd.francetelecom.fr> Thread-Topic: AAAEXT charter, Take 1 Thread-Index: AcQXP1x6+PpjriL2Q1SbOtmNJN/cwAAAKQ3Q From: "MORAND Lionel FTRD/DAC/ISS" To: , "Richard Perlman" , "Bernard Aboba" Cc: "Radius Extensions" 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 : owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 16:45:26 +0000 From: Greg Weber Message-Id: <200403311643.LAA07819@cisco.com> Subject: Re: AAAEXT charter, Take 1 To: aboba@internaut.com (Bernard Aboba) Date: Wed, 31 Mar 2004 11:43:53 -0500 (EST) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 16:40:19 +0000 Message-ID: <406AF3B0.1080204@piuha.net> Date: Wed, 31 Mar 2004 19:37:04 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Richard Perlman , Bernard Aboba Cc: Radius Extensions Subject: Re: AAAEXT charter, Take 1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 16:23:04 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AAAEXT charter, Take 1 Date: Wed, 31 Mar 2004 19:14:21 +0300 Message-ID: Thread-Topic: AAAEXT charter, Take 1 Thread-Index: AcQXOnGKNMht2z9BQf2zUUObWrcxBgAAGnWw From: To: , , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 15:58:58 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 31 Mar 2004 07:58:33 -0800 Subject: Re: AAAEXT charter, Take 1 From: Richard Perlman To: Bernard Aboba , Radius Extensions Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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" 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 15:44:49 +0000 Date: Wed, 31 Mar 2004 07:51:55 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RE: AAAEXT charter, Take 1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Mar 2004 05:33:55 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Wed, 31 Mar 2004 08:31:24 +0300 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQRgd1lJ0Y71LHMRkGHzhAXfDHB0gFX04og From: To: , Cc: 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 >=20 > Operations and Management Area Director(s): > David Kessens > Bert Wijnen >=20 > Operations and Management Area Advisor: > David Kessens >=20 > Technical Advisor: > Paul Congdon >=20 > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Mar 2004 21:00:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SPAM: AW: structured string attributes, RADEXT charter, Take 8 Date: Fri, 26 Mar 2004 15:59:59 -0500 Message-ID: Thread-Topic: SPAM: AW: structured string attributes, RADEXT charter, Take 8 Thread-Index: AcQSP0zYTGr9HG4nS86tPrP+MCWQCwBLw43g From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 20:17:23 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 --- The Prepaid Attributes Date: Thu, 25 Mar 2004 15:17:11 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aboba@internaut.com] > Sent: Thursday, March 25, 2004 3:04 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 19:55:43 +0000 Date: Thu, 25 Mar 2004 12:03:47 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 19:48:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 14:47:34 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQSkeX85/cCXbMiSvmpAqsQnnbXjwAD57qw From: "Nelson, David" To: > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 19:44:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8; dictionaries Date: Thu, 25 Mar 2004 14:43:21 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8; dictionaries Thread-Index: AcQSnt9q9zOzi+N2SCuVDfJLOUYJxAAAiZ2w From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 19:24:36 +0000 To: radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8; dictionaries Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Mar 2004 20:23:41 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1B6aS5-26ymKe0@fwd06.sul.t-online.com> 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 17:58:06 +0000 Date: Thu, 25 Mar 2004 10:06:16 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Review of RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 "eng%nancy@bigu.edu" 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: bernarda@microsoft.com. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 17:52:31 +0000 Message-Id: <4.3.2.7.2.20040325094917.04584248@franklin.cisco.com> Date: Thu, 25 Mar 2004 09:52:01 -0800 To: "Nelson, David" , From: Parviz Yegani Subject: RE: RADEXT charter, Take 8 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_41949049==_.ALT" --=====================_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 radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: --=====================_41949049==_.ALT Content-Type: text/html; charset="us-ascii" 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
--=====================_41949049==_.ALT-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 17:04:31 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 12:03:55 -0500 MIME-Version: 1.0 Content-Type: text/plain > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 15:48:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 10:43:54 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQSfFK69jdV4paRRyehukRPYOJXRwAARg5Q From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 15:26:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 10:22:42 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQSd8fRKpM0Z2JYSpahYxBtl0jieAABAt4g From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 15:17:15 +0000 Message-Id: <5.1.0.14.0.20040325100818.02245ac0@localhost> Date: Thu, 25 Mar 2004 10:16:39 -0500 To: From: "Joel M. Halpern" Subject: RE: RADEXT charter, Take 8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 15:08:12 +0000 Message-ID: From: "Lila Madour (QA/EMC)" To: "'Avi Lior'" , "'jari.arkko@piuha.net'" Cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 09:05:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Some small clarification inline.. /L -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior Sent: Wednesday, March 24, 2004 6:39 PM To: 'jari.arkko@piuha.net'; Avi Lior Cc: radiusext@ops.ietf.org 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. 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. 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:jari.arkko@piuha.net] > Sent: Wednesday, March 24, 2004 4:07 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 14:45:20 +0000 Message-Id: <4.3.2.7.2.20040325060917.01ec41a8@franklin.cisco.com> Date: Thu, 25 Mar 2004 06:45:03 -0800 To: "Nelson, David" , From: Parviz Yegani Subject: RE: RADEXT charter, Take 8 Cc: avi Lior , BeckW@t-systems.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 14:24:52 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: AW: interpreted vs un-interpreted attributes; RADEXT charter, Tak e 8 Date: Thu, 25 Mar 2004 15:24:33 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 14:01:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 08:56:28 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQR+Ua55O+3fljsTt+FYXSol+RLtQAdXYrg From: "Nelson, David" To: 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. =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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 13:13:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 08:10:29 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQR/xDvGc4b19U2QQ+l8uq2bD9tswAZ5+ng From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 07:58:37 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: AW: structured string attributes, RADEXT charter, Take 8 Date: Thu, 25 Mar 2004 08:58:08 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 03:49:16 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Jari Arkko Cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 22:49:09 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aboba@internaut.com] > Sent: Wednesday, March 24, 2004 9:51 PM > To: Jari Arkko > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 03:37:18 +0000 Message-ID: From: Avi Lior To: "'Joel M. Halpern'" , radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 22:36:49 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:joel@stevecrocker.com] > Sent: Wednesday, March 24, 2004 9:51 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 02:51:07 +0000 Message-Id: <5.1.0.14.0.20040324214723.02278bc8@localhost> Date: Wed, 24 Mar 2004 21:50:30 -0500 To: radiusext@ops.ietf.org From: "Joel M. Halpern" Subject: Re: RADEXT charter, Take 8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 02:43:05 +0000 Date: Wed, 24 Mar 2004 18:51:23 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 02:34:51 +0000 Date: Wed, 24 Mar 2004 18:42:50 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: Avi Lior , radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Mar 2004 00:20:43 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 19:20:34 -0500 MIME-Version: 1.0 Content-Type: text/plain I wont say much on this either except: Point 1: An attribute of type string containing multiple elements of data is already in common use in RADIUS and DIAMTER. We already gave you lots of examples of that. Point 2: Seems to me that you are the only one having issues with this. Looking at past emails the consensus seems to be that Attribute falling into my point 1 (above) are okay. Its only when we start talking about a new RADIUS attribute type called SUBTYPE that we have further discussion. There is no draft infront of us that want this. But if you want to create this new attribute be my guest. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, March 24, 2004 4:59 PM > To: radiusext@ops.ietf.org > Subject: RE: RADEXT charter, Take 8 > > > Wolfgang Beck Writes... > > > If this does not translate into 'string attributes must not be > > structured', I can live with it. > > What is a structured string? It could be: > > - XML > - HTTP > - X.500 directory name > - X.509 certificate > - A sonnet > - A limerick > - The collected works of William Shakespeare > > A structured string could also be a binary protocol encoding > (such as a TLV 3-tuple) represented as printable ASCII (or > UTF-8) characters. > > I may be confusing your posts with someone else, but I seem > to recall that you were advocating one or more of the above > definitions of structured string. > > *If* the intent of structured strings is to "hide" > multi-level (nested) sub-attributes in a "bag of > undistinguished octets", only to later open that bag and > effectively "get around" the requirements for compatibility > with existing RADIUS RFCs and recommended attribute formats, > then you equally know my opinion about this! :-) *If* we > are ever to embrace complex, multi-level sub-attributes, we > need to do it explicitly, following the process outlined in > the draft charter (Take 8). > > > You know my opinion about this. > > I think I do. But maybe you could refresh my memory. > Basically, your position is that "flat" RADIUS TLV attributes > are "bad". They cramp one's creativity, flexibility and the > ability to arbitrarily "group" data items, as you could in a > C-language data structure or as in an SMIv2 based MIB. Is > that correct? > > -- Dave > > > > > > > > > > > > > > > Wolfgang > > > > > > > > -- > > to unsubscribe send a message to > radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 23:38:59 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 18:38:38 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:jari.arkko@piuha.net] > Sent: Wednesday, March 24, 2004 4:07 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 22:08:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 16:58:56 -0500 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQR5xvr9n1lvCa5Se6fo0del+TJYAAAYHRg From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 21:29:08 +0000 To: radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Mar 2004 22:28:31 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1B6FvQ-1Qeteq0@fwd10.sul.t-online.com> 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 21:09:54 +0000 Message-ID: <4061F867.3040404@piuha.net> Date: Wed, 24 Mar 2004 23:06:47 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 17:17:32 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 12:16:59 -0500 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 09:16:37 +0000 Message-ID: <40615134.4060605@piuha.net> Date: Wed, 24 Mar 2004 11:13:24 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter, Take 8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 > > Operations and Management Area Director(s): > David Kessens > Bert Wijnen > > Operations and Management Area Advisor: > David Kessens > > Technical Advisor: > Paul Congdon > > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, 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 Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 03:34:59 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter, Take 8 Date: Wed, 24 Mar 2004 05:34:52 +0200 Message-ID: Thread-Topic: RADEXT charter, Take 8 Thread-Index: AcQRT9k0O/KD1b1GRIKUgrp1yOypMQAAGgZg From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba > Sent: 24 March, 2004 5:34 AM > To: radiusext@ops.ietf.org > Subject: RADEXT charter, Take 8 >=20 >=20 > RADIUS Extensions Working Group (RADEXT) Charter > Last Modified: 2004-03-23 >=20 > Chair(s): > David Nelson >=20 > Operations and Management Area Director(s): > David Kessens > Bert Wijnen >=20 > Operations and Management Area Advisor: > David Kessens >=20 > Technical Advisor: > Paul Congdon >=20 > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Mar 2004 03:26:11 +0000 Date: Tue, 23 Mar 2004 19:34:14 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT charter, Take 8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADIUS Extensions Working Group (RADEXT) Charter Last Modified: 2004-03-23 Chair(s): David Nelson Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 23 Mar 2004 17:43:54 +0000 Message-ID: <406076A9.7090704@piuha.net> Date: Tue, 23 Mar 2004 19:40:57 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Bernard Aboba Cc: "Blair T. Bullock" , radiusext@ops.ietf.org Subject: Re: Private NAIs (Was: Re: rfc2486bis) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 23 Mar 2004 15:48:43 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: rfc2486bis Date: Tue, 23 Mar 2004 15:25:27 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223A6@esebe023.ntc.nokia.com> Thread-Topic: rfc2486bis Thread-Index: AcQNpYPlRq76G7A3QtWufe8YRNV/uACoEH9gACTS3TA= From: To: , Cc: 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 "intermediary.com!user@example.com" 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/user@example.com" 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 ("home.example.com!user@intermediary.example.com"). Another possibility would be "ipass/user@example.com", 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: jari.arkko@piuha.net > Cc: radiusext@ops.ietf.org > 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. user@foo.com 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 blair@216.239.97.170 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/user@foo.com and or chained > suffix to do so, i.e. user@foo.com@IPASS or > user@foo.com@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. IPASS%user@foo.com or ipass!user@foo.com 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 ... user@foo.com to > "foo.com!user@intermediary.com" >=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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 23 Mar 2004 15:24:04 +0000 Date: Tue, 23 Mar 2004 07:32:04 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: "Blair T. Bullock" , radiusext@ops.ietf.org Subject: Re: Private NAIs (Was: Re: rfc2486bis) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 23 Mar 2004 12:01:51 +0000 Message-ID: <40602678.8020805@piuha.net> Date: Tue, 23 Mar 2004 13:58:48 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Blair T. Bullock" Cc: radiusext@ops.ietf.org Subject: Private NAIs (Was: Re: rfc2486bis) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 :-( > user@foo.com 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 blair@216.239.97.170 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Mar 2004 20:04:00 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: rfc2486bis Date: Mon, 22 Mar 2004 12:01:11 -0800 Message-ID: Thread-Topic: rfc2486bis Thread-Index: AcQNpYPlRq76G7A3QtWufe8YRNV/uACoEH9g From: "Blair T. Bullock" To: jari.arkko@piuha.net cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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. user@foo.com 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 blair@216.239.97.170 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/user@foo.com and or chained suffix to do so, i.e. user@foo.com@IPASS or user@foo.com@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. IPASS%user@foo.com or ipass!user@foo.com 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 ... user@foo.com to=20 "foo.com!user@intermediary.com" ...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:bwijnen@lucent.com]=20 Sent: Friday, March 19, 2004 3:28 AM To: stefaan.de_cnodder@alcatel.be; jari.arkko@piuha.net Cc: radiusext@ops.ietf.org 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: "eng!nancy@bigu.edu" 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: someone@example.com foo@bar.example.com 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 eng%nancy@bigu.edu 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 > > eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with=20 > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 14:32:32 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0C33@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: radiusext@ops.ietf.org Subject: FW: Example domain names (Was: Re: rfc2486bis) Date: Fri, 19 Mar 2004 15:32:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jari Not the answer you wanted I guess... but. Thanks, Bert=20 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] 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:jari.arkko@piuha.net] > Sent: vrijdag 19 maart 2004 12:41 > To: Wijnen, Bert (Bert) > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 13:52:49 +0000 Message-ID: <405AFA77.6080805@piuha.net> Date: Fri, 19 Mar 2004 15:49:43 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be Cc: "'radiusext@ops.ietf.org'" Subject: Re: rfc2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit stefaan.de_cnodder@alcatel.be 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 11:58:58 +0000 Date: Fri, 19 Mar 2004 04:00:31 -0800 (PST) From: Bernard Aboba To: "Wijnen, Bert (Bert)" cc: stefaan.de_cnodder@alcatel.be, jari.arkko@piuha.net, radiusext@ops.ietf.org Subject: RE: rfc2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I hope/assume that everyone knows/understands that we do not accept > such examples in RFCs. We want them to be of the form: > > someone@example.com > foo@bar.example.com > > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 11:58:20 +0000 Message-ID: <405ADFB6.3000709@piuha.net> Date: Fri, 19 Mar 2004 13:55:34 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: rfc2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 11:51:09 +0000 Date: Fri, 19 Mar 2004 03:59:11 -0800 (PST) From: Bernard Aboba To: stefaan.de_cnodder@alcatel.be cc: jari.arkko@piuha.net, radiusext@ops.ietf.org Subject: Re: rfc2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 11:43:55 +0000 Message-ID: <405ADC47.6060901@piuha.net> Date: Fri, 19 Mar 2004 13:40:55 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: radiusext@ops.ietf.org Subject: Example domain names (Was: Re: rfc2486bis) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 11:29:04 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0B8D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: stefaan.de_cnodder@alcatel.be, jari.arkko@piuha.net Cc: radiusext@ops.ietf.org Subject: RE: rfc2486bis Date: Fri, 19 Mar 2004 12:28:24 +0100 MIME-Version: 1.0 Content-Type: text/plain > 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: "eng!nancy@bigu.edu" 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: someone@example.com foo@bar.example.com 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 eng%nancy@bigu.edu 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. > > > > eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 09:41:35 +0000 Message-ID: <405AC03D.D2E770FA@alcatel.be> Date: Fri, 19 Mar 2004 10:41:17 +0100 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: jari.arkko@piuha.net CC: radiusext@ops.ietf.org Subject: Re: rfc2486bis Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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: "eng!nancy@bigu.edu" 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 eng%nancy@bigu.edu 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. > > eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Mar 2004 09:05:48 +0000 Message-ID: <405AB7BF.95630A92@alcatel.be> Date: Fri, 19 Mar 2004 10:05:03 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: jari.arkko@piuha.net CC: stefaan.de_cnodder@alcatel.be, Bernard Aboba , radiusext@ops.ietf.org Subject: Re: rfc2486bis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Mar 2004 18:48:22 +0000 Message-ID: <4059EE2B.2070407@piuha.net> Date: Thu, 18 Mar 2004 20:44:59 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: rfc2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>1) examples in section 2.8: why is @howard.edu an invalid NAI? And >>why has eng%nancy@bigu.edu 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. eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Mar 2004 16:22:16 +0000 Date: Thu, 18 Mar 2004 08:23:48 -0800 (PST) From: Bernard Aboba To: stefaan.de_cnodder@alcatel.be cc: radiusext@ops.ietf.org Subject: Re: rfc2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 1) examples in section 2.8: why is @howard.edu an invalid NAI? And > why has eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Mar 2004 15:52:24 +0000 Message-ID: <4059C57E.59C1C7F3@alcatel.be> Date: Thu, 18 Mar 2004 16:51:26 +0100 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: rfc2486bis Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 eng%nancy@bigu.edu 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 17 Mar 2004 05:42:05 +0000 Message-ID: <4057E5F1.6090104@lab.ntt.co.jp> Date: Wed, 17 Mar 2004 14:45:21 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment - Take 7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 16 Mar 2004 20:19:25 +0000 Date: Tue, 16 Mar 2004 12:28:19 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT charter for comment - Take 7 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADIUS Extensions Working Group (RADEXT) Charter Last Modified: 2004-03-16 Chair(s): David Nelson Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 16 Mar 2004 18:26:55 +0000 Message-Id: <5.1.0.14.0.20040316132122.02394da0@localhost> Date: Tue, 16 Mar 2004 13:26:04 -0500 To: radiusext@ops.ietf.org From: "Joel M. Halpern" Subject: Re: RADEXT charter for comment... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 18:47:21 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: radiusext@ops.ietf.org Subject: Invited papers for CCCT04 Date: Fri, 12 Mar 2004 12:46:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 18:16:20 +0000 Date: Fri, 12 Mar 2004 10:25:17 -0800 (PST) From: Bernard Aboba To: "Adrangi, Farid" cc: stefaan.de_cnodder@alcatel.be, radiusext@ops.ietf.org Subject: RE: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 18:11:56 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 20:08:02 +0200 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQITIyjW33pttHOTz+eBpRt1aw2ggAECxjQ From: To: , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 16:42:13 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 18:41:46 +0200 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQIT47c2ig6JCq6T1qUFIVtzmvvVAAAS30Q From: To: , , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 16:33:13 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 11:32:54 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQH8ck2oJHlOADzQYOvkLYQrdC/2gAW8seA From: "Nelson, David" To: "Barney Wolff" , "Bernard Aboba" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 16:29:30 +0000 Message-ID: <4051E4CE.6010001@piuha.net> Date: Fri, 12 Mar 2004 18:26:54 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Bernard Aboba , Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 16:29:15 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 08:28:37 -0800 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHn7nvuImThLh7Q/yOcLQBAmG9QQArwp1Q From: "Adrangi, Farid" To: , "Bernard Aboba" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 16:06:51 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba ' , "'john.loughney@nokia.com '" Cc: "'radiusext@ops.ietf.org '" Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 11:06:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: john.loughney@nokia.com Cc: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 15:58:40 +0000 Message-ID: From: Avi Lior To: 'Korhonen Jouni ' , "'Adrangi, Farid '" , "'radiusext@ops.ietf.org '" Cc: "'aboba@internaut.com '" , "'dnelson@enterasys.com '" , "'bwijnen@lucent.com '" , "'david.kessens@nokia.com '" Subject: RE: RADIUSExt BoF minutes Date: Fri, 12 Mar 2004 10:58:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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; radiusext@ops.ietf.org Cc: aboba@internaut.com; dnelson@enterasys.com; bwijnen@lucent.com; david.kessens@nokia.com 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:farid.adrangi@intel.com] > Sent: 11. maaliskuuta 2004 10:23 > To: radiusext@ops.ietf.org > Cc: aboba@internaut.com; dnelson@enterasys.com; > bwijnen@lucent.com; david.kessens@nokia.com > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 15:50:36 +0000 Date: Fri, 12 Mar 2004 07:59:50 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 15:04:02 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 10:02:45 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQH5gCNOdveVhdmRbmhZEryjTZu2wAXBvzg From: "Nelson, David" To: "Bernard Aboba" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 09:42:53 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUSExt BoF minutes Date: Fri, 12 Mar 2004 11:42:11 +0200 Message-ID: Thread-Topic: RADIUSExt BoF minutes Thread-Index: AcQHQhU879F0JmZ6TzigbLgYM6ntzgA08VFA From: "Korhonen Jouni" To: "Adrangi, Farid" , Cc: , , , 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:farid.adrangi@intel.com]=20 > Sent: 11. maaliskuuta 2004 10:23 > To: radiusext@ops.ietf.org > Cc: aboba@internaut.com; dnelson@enterasys.com;=20 > bwijnen@lucent.com; david.kessens@nokia.com > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 08:51:37 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 10:50:41 +0200 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQICMs1orXSVwnNSbGiNFtrzWSJSQABjsNA From: To: Cc: , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 08:31:21 +0000 Message-ID: <40517534.F81BA144@alcatel.be> Date: Fri, 12 Mar 2004 09:30:44 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > * 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 08:05:06 +0000 Message-ID: <40516E99.1040708@piuha.net> Date: Fri, 12 Mar 2004 10:02:33 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 07:23:30 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Fri, 12 Mar 2004 09:22:31 +0200 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHhYMOPTrHxD3UR9qMNA8Ad4MxNgAfN93A From: To: , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 05:21:25 +0000 Date: Fri, 12 Mar 2004 00:20:49 -0500 From: Barney Wolff To: Bernard Aboba Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Message-ID: <20040312052049.GA23491@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 03:56:45 +0000 Date: Thu, 11 Mar 2004 20:04:03 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 03:41:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Thu, 11 Mar 2004 22:36:49 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQH3qGyAK72tx+NTXujPjZwLAAx8wAAlMIw From: "Nelson, David" To: "Bernard Aboba" Cc: > > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 03:05:53 +0000 Date: Thu, 11 Mar 2004 19:15:15 -0800 (PST) From: Bernard Aboba To: Barney Wolff cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Mar 2004 03:04:08 +0000 Date: Thu, 11 Mar 2004 19:13:15 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 21:02:59 +0000 Date: Thu, 11 Mar 2004 16:01:54 -0500 From: Barney Wolff To: Bernard Aboba Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Message-ID: <20040311210154.GB29490@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 19:39:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Thu, 11 Mar 2004 14:39:19 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHny6wF7Q7ovyoTFukyCW8QH5YGQAAG0nA From: "Nelson, David" To: "Bernard Aboba" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 19:33:13 +0000 Message-ID: <4050BED7.F0A5910C@alcatel.be> Date: Thu, 11 Mar 2004 20:32:39 +0100 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > - 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 19:29:56 +0000 Date: Thu, 11 Mar 2004 11:39:09 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 19:22:54 +0000 Date: Thu, 11 Mar 2004 11:31:58 -0800 (PST) From: Bernard Aboba To: "Joel M. Halpern" cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 18:39:01 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Thu, 11 Mar 2004 13:38:31 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHjXWYi1X7mVgtQCudC7MYatHOTwACZZ3Q From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 18:30:50 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Thu, 11 Mar 2004 13:30:26 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHisk9Tc5FHTg7RXOslRelmJ5uNAAC8N+g From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 17:22:02 +0000 Message-Id: <5.1.0.14.0.20040311121831.0223ba18@localhost> Date: Thu, 11 Mar 2004 12:21:13 -0500 To: Bernard Aboba From: "Joel M. Halpern" Subject: Re: RADEXT charter for comment... Cc: radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 17:03:42 +0000 Message-Id: <5.1.0.14.0.20040311120202.0224b290@localhost> Date: Thu, 11 Mar 2004 12:03:24 -0500 To: "Nelson, David" , "Bernard Aboba" , From: "Joel M. Halpern" Subject: RE: RADEXT charter for comment... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 17:03:16 +0000 Date: Thu, 11 Mar 2004 09:12:41 -0800 (PST) From: Bernard Aboba To: "Joel M. Halpern" cc: radiusext@ops.ietf.org Subject: Re: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 16:54:50 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT charter for comment... Date: Thu, 11 Mar 2004 11:53:25 -0500 Message-ID: Thread-Topic: RADEXT charter for comment... Thread-Index: AcQHhPzcH4CAAOjtQoef7uO6fLncxgAAwC4Q From: "Nelson, David" To: "Bernard Aboba" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 16:21:35 +0000 Date: Thu, 11 Mar 2004 08:31:01 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT charter for comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 16:06:42 +0000 Date: Thu, 11 Mar 2004 08:15:50 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for review: Diameter NASREQ specification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: 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 (aaa-wg@merit.edu) 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 14:32:12 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Bar BoF minutes; Reviewer for RADIUSEXT SIP drafts Date: Thu, 11 Mar 2004 15:31:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 09:59:18 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUSExt BoF minutes Date: Thu, 11 Mar 2004 11:58:46 +0200 Message-ID: Thread-Topic: RADIUSExt BoF minutes Thread-Index: AcQHQhU879F0JmZ6TzigbLgYM6ntzgADQ7mg From: "Romascanu, Dan (Dan)" To: "Adrangi, Farid" , Cc: , , , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid > Sent: 11 March, 2004 10:23 AM > To: radiusext@ops.ietf.org > Cc: aboba@internaut.com; dnelson@enterasys.com;=20 > bwijnen@lucent.com; david.kessens@nokia.com > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Mar 2004 08:24:12 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C40742.171AA682" Subject: RADIUSExt BoF minutes Date: Thu, 11 Mar 2004 00:23:11 -0800 Message-ID: Thread-Topic: RADIUSExt BoF minutes Thread-Index: AcQHQhU879F0JmZ6TzigbLgYM6ntzg== From: "Adrangi, Farid" To: Cc: , , , 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///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARUAJBAAA8BK/AAAAAAAAEAAAAAAABgAAGxgAAA4AYmpiaoPmg+YAAAAAAAAAAAAAAAAAAAAA AAAJBBYAJSQAAOGMAQDhjAEAGxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAIQBAAAAAAAAhAEAAIQB AAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAhAEAABQAAAAAAAAAAAAAAJgBAAAAAAAAIAoA AAAAAAAgCgAAAAAAACAKAAAAAAAAIAoAABQAAAA0CgAAFAAAAJgBAAAAAAAAXRgAAKABAABUCgAA AAAAAFQKAAAAAAAAVAoAAAAAAABUCgAAAAAAAFQKAAAAAAAAVAoAAAAAAABUCgAAAAAAAFQKAAAA AAAAtBcAAAIAAAC2FwAAAAAAALYXAAAAAAAAthcAAAAAAAC2FwAAAAAAALYXAAAAAAAAthcAACQA AAD9GQAAUgIAAE8cAACIAAAA2hcAABUAAAAAAAAAAAAAAAAAAAAAAAAAhAEAAAAAAACjCwAAAAAA AAAAAAAAAAAAAAAAAAAAAABUCgAAAAAAAFQKAAAAAAAAowsAAAAAAACjCwAAAAAAANoXAAAAAAAA AAAAAAAAAACEAQAAAAAAAIQBAAAAAAAAVAoAAAAAAAAAAAAAAAAAAFQKAAAAAAAA7xcAADIAAACf DQAAAAAAAJ8NAAAAAAAAnw0AAAAAAACjCwAAigEAAIQBAAAAAAAAVAoAAAAAAACEAQAAAAAAAFQK AAAAAAAAtBcAAAAAAAAAAAAAAAAAAJ8NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAowsAAAAAAAC0FwAAAAAAAJ8NAABsAAAAnw0AAAAAAAALDgAA VgAAAKQWAABAAAAAhAEAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaBcAAAAAAABUCgAAAAAAAEgKAAAMAAAAgPTJ+UAH xAEAAAAAAAAAACAKAAAAAAAALQ0AAEYAAADkFgAADAAAAAAAAAAAAAAAmBcAABwAAAAhGAAAPAAA AF0YAAAAAAAA8BYAAHgAAADXHAAAAAAAAHMNAAAiAAAA1xwAABgAAABoFwAAAAAAAAAAAAAAAAAA mAEAAAAAAACYAQAAAAAAAIQBAAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAAAAAAAAAAAAA AAAAAAAAANccAAAAAAAAAAAAAAAAAACEAQAAAAAAAGgXAAAwAAAAVAoAADAAAACECgAAIgAAAJ8N AAAAAAAApgoAABwAAADCCgAA4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAoA AAAAAABUCgAAAAAAAFQKAAAAAAAA2hcAAAAAAADaFwAAAAAAAJgBAAAAAAAAmAEAAEQEAADcBQAA RAQAAAAAAAAAAAAAlQ0AAAoAAACYAQAAAAAAAJgBAAAAAAAA3AUAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NUkFE SVVTRVhUIEJvRiBNaW51dGVzIA1JRVRGLTU5IJYgU2VvdWwsIEtvcmVhDQ1BdHRlbmRlZXM6IA1K YXJpIEFya2tvLCBHbGVuIFpvcm4gLCBQYXNpIEVyb25lbiwsIFNlcmdlIG1hbm5pbmcsIE9zb2sg U29uZywgSm9lbCBIYWxwZXJuLCAgU3RlZmFhbiBDbm9kZGVyLCBXb2xmZ2FuZyBCZWNrLCBBdmkg TGlvciwgLCBGYXJpZCBBZHJhbmdpLCBQYXJ2aXogWWVnYW5pLiAgTm90ZTogIHNvbWUgb2YgdGhl IGZvbGtzIHdlcmUgbm90IGFibGUgdG8gYXR0ZW5kIGR1ZSB0byB0aW1lIGNvbmZsaWN0IHdpdGgg dGhlIHNvY2lhbCBldmVudCENDQ1TdW1tYXJ5Og1UaGUgZ3JvdXAgcmVhY2hlZCBjb25zZW5zdXMg dGhhdCB0aGUgUkFESVVFWFQgY2hhcnRlciBzaG91bGQgZm9jdXMgb24gdGhyZWUgbWFpbiB3b3Jr IGNhdGVnb3JpZXM6IExBTiBhdHRyaWJ1dGVzLCBQcmVwYWlkLCBhbmQgU0lQLiAgIA0NVGhlIGdy b3VwIGFsc28gcmVhY2hlZCBjb25zZW5zdXMgdGhhdCBib3RoIFJBRElVUyBhbmQgRGlhbWV0ZXIg cHJvdG9jb2xzIGFyZSByZWxldmFudCwgYW5kIHRoYXQgZm9yIGVhY2ggd29yayBpdGVtIGl0IHNo YWxsIGJlIGRldGVybWluZWQgd2hldGhlciBpdCBhcHBsaWVzIHRvIGJvdGggKHN1Y2ggYXMgYXR0 cmlidXRlcyB1c3VhbGx5IHdvdWxkKSBvciBqdXN0IFJBRElVUyAoZS5nLiBiZWNhdXNlIHRoZXJl IGFscmVhZHkgaXMgYSBjb3JyZXNwb25kaW5nIERpYW1ldGVyIGFwcGxpY2F0aW9uKS4gVGhlIHN1 Z2dlc3RlZCBuYW1lIG9mIHRoZSBncm91cCB3b3VsZCBiZSBBQUEgRXh0ZW5zaW9ucyBXRyAoQUFB RVhUKS4NDUEgbnVtYmVyIG9mIGluZGl2aWR1YWxzIHZvbHVudGVlcmVkIHRvIHJldmlldyB0aGUg Y3VycmVudGx5IHB1Ymxpc2hlZCBkcmFmdHMgaW4gYWZvcmVtZW50aW9uZWQgY2F0ZWdvcmllcy4g IFRoZSBsaXN0IGFwcGVhcnMgYmVsb3cuDQ1EaXNjdXNzaW9uczoNDUV2ZXJ5b25lIGFncmVlZCB0 aGUgcHJvcG9zZWQgd29yayBpdGVtcyBpbiB0aGUgY2hhcnRlciBzaG91bGQgbm90IGJyZWFrIFJB RElVUyCWIGkuZS4sIHNob3VsZCBiZSAgYmFja3dhcmQgY29tcGF0aWJsZS4gICAgDQ1KYXJpIHBv aW50ZWQgb3V0IHRoYXQgaXQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0byBuYW1lIHRoZSBXRyBBQUFF WFQgYXMgd2UgbWF5IHdhbnQgdG8gZGVmaW5lIHNvbWUgb2YgdGhlIExBTiBhdHRyaWJ1dGVzIGlu IGJvdGggUkFESVVTIGFuZCBEaWFtZXRlci4gICBUaGlzIGluaXRpYXRlZCBmdXJ0aGVyIGRpc2N1 c3Npb24gb24gd2hldGhlciBib3RoIGZvcm1hdHMgc2hvdWxkIGJlIGRlZmluZWQgaW4gYSBzaW5n bGUgZHJhZnQgb3Igc2VwYXJhdGUgb25lcy4gIEF2aSBleHByZXNzZWQgY29uY2VybiB0aGF0IFJB RElVUyBkcmFmdCBhdXRob3JzIG1heSBub3QgbmVjZXNzYXJpbHkgYmUgZXhwZXJ0IGluIERpYW1l dGVyLiBKb2VsIHNhaWQgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gUkFESVVTLCBhbmQgaWYgc29t ZW9uZSB3YW50cyB0byBkbyBpdCBmb3IgZGlhbWV0ZXIgb3V0c2lkZSB0aGlzIGdyb3VwLCB0aGVu IHRoYXSScyBmaW5lLiAgSmFyaSBhbmQgUGFzaSBzYWlkIHRoYXQgY3JlYXRpbmcgUkFESVVTIGF0 dHJpYnV0ZXMgd2l0aG91dCBpbnRyb2R1Y2luZyB0aGVpciBlcXVpdmFsZW5jZSBpbiBEaWFtZXRl ciBtYXkgY3JlYXRlIHByb2JsZW0uICBGdXJ0aGVybW9yZSBoZSBzYWlkIHdlIHNob3VsZCBsb29r IGF0IGVhY2ggaW5kaXZpZHVhbCB3b3JrIGl0ZW0sIGFuZCBkZWNpZGUgd2hldGhlciB3ZSBzaG91 bGQgZG8gaXQgZm9yIGJvdGggKERpYW1ldGVyIGFuZCBSQURJVVMpIG9yIGZvciBSQURJVVMgb25s eS4gRm9yIGV4YW1wbGUsIFNJUCBhbmQgUHJlcGFpZCBzaG91bGQgYmUgZG9uZSBmb3IgUkFESVVT IG9ubHkuICAgSm9lbCBzYWlkIHRoYXQgaXQgaXMgZWFzaWVyIHRvIGNoYXJ0ZXIgdGhlIFdHIGlm IHdlIGRvbpJ0IG1lbnRpb24gRGlhbWV0ZXIuICBBdCB0aGUgZW5kIHRoZXJlIHdhcyBhIGNvbnNl bnN1cyB0byBkbyBib3RoIHdvcmsgaW4gdGhlIHNhbWUgZ3JvdXAgYW5kIHRvIGNvbnNpZGVyIHdo ZXRoZXIgYSB3b3JrIGl0ZW0gY292ZXJzIGJvdGggUkFESVVTIGFuZCBEaWFtZXRlciBvbiBhIGNh c2UtYnktY2FzZSBiYXNpcy4NDVRoZXJlIHdhcyBhIGNvbmNlcm4gYWJvdXQgdGhlIG51bWJlciBv ZiB0aGUgZHJhZnRzIHRoYXQgd2VyZSBwb3N0ZWQgb24gdGhlIGxpc3QuICBMYXJnZSBudW1iZXIg b2YgZHJhZnRzIGRlbW9uc3RyYXRzIHRoZSBoaWdoIGludGVyZXN0LiAgQnV0IHRoZSBncm91cCBm ZWx0IHRoYXQgdGhpcyBhbW91bnQgb2Ygd29yayB3YXMgbm90IGRvYWJsZSwgYW5kIHRoZSBjaGFy dGVyIGEgbGFyZ2UgbnVtYmVyIG9mIHdvcmsgaXRlbXMgbWlnaHQgYWxzbyBub3QgYmUgcG9zc2li bGUuICBBdmkgcG9pbnRlZCBvdXQgdGhlIGluIHRoZSBjYXNlIG9mIFBXTEFOLCBkaXNjdXNzaW9u cyBvbiB0aGUgbGlzdCByZXF1ZXN0ZWQgdGhhdCB3ZSBzcGxpdCB0aGUgUFdMQU4gYXR0cmlidXRl cyBpbnRvIHNldmVyYWwgZHJhZnRzLiAgVGhpcyBjcmVhdGVkIHRoZSBpbGx1c2lvbiBvZiB0cmVt ZW5kb3VzIGFtb3VudCBvZiB3b3JrIGJ1dCBpdCByZWFsaXR5IG1hbnkgb2YgdGhlIGRyYWZ0cyBh cmUgc3RyYWlnaHRmb3J3YXJkLiAgSXQgd2FzIGRlY2lkZWQgdGhhdCBpdCB3b3VsZCBiZSBiZXN0 IHRvIGdyb3VwIHRoZSBkcmFmdHMgaW50byBmdW5jdGlvbmFsIGNhdGVnb3JpZXMgaW4gdGhlIGNo YXJ0ZXIgdG8gYmV0dGVyIHJlcHJlc2VudCB0aGUgd29yayB0byBiZSBhY2NvbXBsaXNoZWQuICBB dmkgdG9vayB0aGlzIGFjdGlvbi4NDUl0IHdhcyBhbHNvIG5vdGVkIHRoYXQgdGhlIGNoYWlycyB3 ZXJlIHB1c2hpbmcgd29yayBvdXQgb2YgdGhlIFJBRElVU0VYVCBXRyBwcm9iYWJseSB0byBsZXNz ZW4gdGhlIGxvYWQuICBUaGUgYWN0aW9uIHRvIG1vdmUgdGhlIGxvY2F0aW9uIGRyYWZ0IHRvIEdl b3ByaXYgd2FzIGJyb3VnaHQgdXAgYXMgYW4gZXhhbXBsZS4gIEdpdmVuIHRoZSBHZW9wcml2IFdH knMgZXhwZXJ0aXNlIGluIHRoaXMgYXJlYSB0aGlzIHdhcyBmZWx0IHRvIG1ha2Ugc2Vuc2UuDQ1X ZSBkaXNjdXNzZWQgd2hhdCB3b3JrIGl0ZW1zIHRoZSBXRyBzaG91bGQgZm9jdXMgb24uICBKb2Vs IHNhaWQgdGhhdCBoZSBjYW6SdCBpbWFnaW5lIGlmIFdHIGNhbiBmb2N1cyBvbiBhbGwgdGhlIGN1 cnJlbnRseSBzdWJtaXR0ZWQgZHJhZnRzLiAgR2xlbiBzYWlkIJNhcmUgc29tZSBvZiB0aGVtIHVu bmVjZXNzYXJ5P5QgIElmIG5vdCwgd2Ugc2hvdWxkIGRvIHRoZW0uICBKYXJpIHNhaWQgdGhhdCB3 ZSBzaG91bGQgZm9jdXMgb24gdGhlIGltcG9ydGFudCBvbmVzLiBBbmQgdGhlbiB3ZSBhc2tlZCBl dmVyeW9uZSB0aGVpciBvcGluaW9uIG9uIHRoaXMgYW5kIHRoYXQgc3VtbWFyaXplZCBpdCB0byA6 IFByZXBhaWQsIFNJUCwgYW5kIExBTiBhdHRyaWJ1dGVzLiAgSmFyaSBzdWdnZXN0ZWQgdGhhdCBp dCBtYXkgYWxzbyBtYWtlIHNlbnNlIHRoYXQgb25seSB0aGUgbW9zdCBpbXBvcnRhbnQgTEFOIGF0 dHJpYnV0ZXMgYXJlIHRha2VuIHRvIHRoZSBjaGFydGVyLiBKb2VzIHNhaWQgd2UgY2FuIGFsd2F5 cyByZWNoYXJ0ZXIgc2hvdWxkIHRoZSBuZWVkIGFyaXNlcy4NDUZhcmlkIGFza2VkIHdobyB2b2x1 bnRlZXJzIHRvIGJlIHJldmlld2VyIGZvciB0aGUgZHJhZnRzIHRoYXQgZmFsbCBpbnRvIHRoZSBz cGVjaWZpZWQgdGhyZWUgd29yayBpdGVtIGNhdGVnb3JpZXMuIA0NIEphcmkgQXJra28gKGFsbCks IFBhc2kgRXJvbmVuIChMQU4gYXR0cmlidXRlcyksIEpvZWwgSGFscGVybiAoUHJlcGFpZCksIE9z b2sgU29uZyAoTEFOIGF0dHJpYnV0ZXMpLCBQYXJ2aXogWWVnYW5pIChQcmVwYWlkLCBMQU4gYXR0 cmlidXRlcyksIERhdmlkIE1hcmlibGFuY2EgKGFsbCAtIHZvbHVudGVlcmVkIGJ5IEphcmkpLCBG YXJpZCBBZHJhbmdpIChhbGwpIGFuZCBBdmkgIExpb3IgKGFsbCkgLCBsaW9uZWwgbW9yYW5kIChM QU4sIFByZXBhaWQpDQ1Kb2VsIHN1Z2dlc3RlZCB0aGF0IHdlIHNob3VsZCBzZXR1cCBhIHByb2Js ZW0gdHJhY2tlciBkYXRhYmFzZSB0byB0cmFjayB0aGUgaXNzdWVzIHN1Ym1pdHRlZCBhZ2FpbnN0 IHRoZSBkcmFmdHMuDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAABCAAAAggAABAI AAAZCAAAIAgAAC8IAAAwCAAAMQgAAD0IAACMCAAAmwgAABQJAAA2CQAAPwkAAMcJAADdCQAAMwsA ADYLAACvCwAAvAsAAEYTAAD22761vrW+mr6af5rbYldPV0dXO1cAAAAAAAAAAAAXFWjxRxYAFmjb WKIANQiBQ0oQAGFKEAAOFmhnO58AQ0oQAGFKEAAADhZo8UcWAENKEABhShAAABQVaPFHFgAWaNtY ogBDShAAYUoQAAA4FWjxRxYAFmjbWKIAQ0oUAE9KAgBRSgIAicoHAQEAA1iDhoMqATUIAUNKEABP SgAAUUoAAGFKEAAANRVo8UcWABZo21iiAENKFABPSgMAUUoDAInKBwEBAANYg4aDKgFDShAAT0oA AFFKAABhShAANRVo8UcWABZo21iiAENKFABPSgIAUUoCAGFKEACJygcBAQADWIOGgyoBQ0oQAE9K AABRSgAAERZo21iiADUIgUNKEABhShAAOBVo8UcWABZo21iiAENKFABPSgIAUUoCAGFKEACJygcB AQADWIOGgyoBNQgBQ0oQAE9KAABRSgAAADUVaPFHFgAWaNtYogBDShQAT0oCAFFKAgCJygcBAQAD WIOGgyoBQ0oQAE9KAABRSgAAYUoQABIWaNtYogBDShQAT0oCAFFKAgAVAAYAAAEIAAACCAAAGQgA ADAIAAAxCAAAPQgAADQJAAA1CQAANgkAAD8JAADGCQAAxwkAACkLAAAqCwAArgsAAK8LAAC8CwAA vQsAADgMAAA5DAAAVBAAAFUQAAD8AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADVAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAA AAAAAADNAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAA yAAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMAAAAAA AAAAAAAAAADIAAAAAAAAAAAAAAAAAAAAAAAACAAACiYAC0YCAGdkpXXtAAAEAABnZPFHFgAIAAAK JgALRgEAZ2TxRxYAAAcAAAMkAWEkAWdk8UcWABEAADEkAGdk8UcWAG/GBwEBAANYg4ZkJgEDJAEx JAFhJAEOAAAxJABnZPFHFgBvxgcBAQADWIOGZCYBMSQBAwAAMSQAABYABgAAGxgAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAVUQAAADEwAABBMAAAkUAAAK FAAAMBYAADEWAACkFgAApRYAAKgXAACpFwAAGhgAABsYAAD3AAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAOoAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAAN8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQACAAACiYAC0YDAGdkpXXtAAgAAAom AAtGAgBnZPFHFgAABAAAZ2TxRxYACAAACiYAC0YCAGdkpXXtAAAMRhMAAEkTAAC8EwAAvhMAANcT AAD3EwAAFxQAADcUAABqFAAAbxQAAP8WAAAXFwAAiRcAAJIXAACYFwAApxcAABoYAAAbGAAA9eri 6trq4ura6tLq4sfi6roAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGBVo8UcWABZo21iiAENKFABPSgIAUUoCAAAUFWilde0AFmilde0AQ0oQAGFK EAAADhZoBBg4AENKEABhShAAAA4WaGc7nwBDShAAYUoQAAAOFmilde0AQ0oQAGFKEAAAFBVo8UcW ABZo21iiAENKEABhShAAABQVaPFHFgAWaPFHFgBDShAAYUoQABEjABIwABxQAQAfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABAAEgABAJwADwADAAQAAAAEAAAARAAAQPH/ AgBEAAwAAAAAAAAAAAAGAE4AbwByAG0AYQBsAAAAAgAAABwAQ0oYAE9KAABRSgAAX0gBBG1ICQRz SAkEdEgJBAAAAAAAAAAAAAAAAAAAAAAAAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUA bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGlA8/+zAFYADAEAAAAAAAAA AAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgABCgNs AGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAA AEgAmUABAPIASAAMAQAA8UcWAAAADABCAGEAbABsAG8AbwBuACAAVABlAHgAdAAAAAIADwAUAENK EABPSgUAUUoFAF5KBQBhShAAAAAAABsQAAAJAAAkAAAIAP////8AAAAAAQAAAAIAAAAZAAAAMAAA ADEAAAA9AAAANAEAADUBAAA2AQAAPwEAAMYBAADHAQAAKQMAACoDAACuAwAArwMAALwDAAC9AwAA OAQAADkEAABUCAAAVQgAAAMLAAAECwAACQwAAAoMAAAwDgAAMQ4AAKQOAAClDgAAqA8AAKkPAAAa EAAAHRAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAEgADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAASAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAABIAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAC IAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIg ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAADIAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAAAAAAAQAAAAIA AAAZAAAAMAAAADEAAAA9AAAANAEAADUBAAA2AQAAPwEAAMYBAADHAQAAKQMAACoDAACuAwAArwMA ALwDAAC9AwAAOAQAADkEAABUCAAAVQgAAAMLAAAECwAACQwAAAoMAAAwDgAAMQ4AAKQOAAClDgAA qA8AAKkPAAAaEAAAHRAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAgAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAgACYAAEgADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAASAAMAEAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAABIAAwAgAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAACIAAwAQAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAIgADACAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAiAAMAMAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAACIAAwBAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAIgADAFAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAADIAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAA BgAARhMAABsYAAANAAAAEQAAAAAGAABVEAAAGxgAAA4AAAAQAAAAAAYAABsYAAAPAAAA//8DAAAA BgCDI6cAAAABAKQbIQAGAIQjpwABAAEAlFMfAAYAhSOnAAEAAQD02BoAIwAAACMAAAAqAAAAHRAA AAEAAAACAAAAAAACAAIAAAACACgAAAAvAAAALwAAAB0QAAABAAEAAAAAAAIAAAADAAAAQgAAAAEA AAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncw6AY291bnRyeS1y ZWdpb24AgDgAAAACAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRh Z3MEgENpdHkAgDkAAAADAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MFgHBsYWNlAIAMAAABAQAAAAAAAAADAAAAAAACAAAAAAABAAAAAAAAAAAADAAAAA8AAAA9 AAAAQQAAAEIAAABHAAAATgAAAFIAAABVAAAAWQAAAFoAAABgAAAAcgAAAHYAAACCAAAAiQAAAIwA AACTAAAAlAAAAJsAAADHAAAAzQAAAM4AAADUAAAAOQQAAD0EAAAXBgAAGwYAACAGAAAkBgAAlwsA AJ4LAADICwAAzwsAANALAADUCwAA3wwAAOMMAACFDQAAiQ0AAA4OAAAXDgAApg4AAKoOAACrDgAA sA4AALgOAAC8DgAAvQ4AAMMOAADbDgAA4g4AAO4OAADyDgAACg8AABAPAAARDwAAFw8AAFoPAABe DwAAiw8AAJEPAACSDwAAmA8AAB0QAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAABsEAAAnBAAA3QUAAN8F AAChBwAAqAcAAF0NAABhDQAABw4AAA0OAAAdEAAABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAAAC AAAAMQAAADYBAAA/AQAAHRAAAAcABQAHAAUABwAAAAAAHRAAAAcA//8IAAAACgBKAGEAcgBpACAA QQBSAGsAawBvAAAACgBKAGEAcgBpACAAQQBSAGsAawBvAAAACgBDAGkAcwBjAG8AIABVAHMAZQBy AAAADQBGAGEAcgBpAGQAIABBAGQAcgBhAG4AZwBpAAAAAwCAPgUMVLQ2tv8P/w//D/8P/w//D/8P /w//DxAAKiyUNdLlugL/D/8P/w//D/8P/w//D/8P/w8QALtzj2gCrPhe/w//D/8P/w//D/8P/w// D/8PEAABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+ T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhDgE EYSY/hXGBQABOAQGXoQ4BGCEmP5PSgMAUUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABUYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAIdo AAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E2AkRhJj+FcYFAAHYCQZe hNgJYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ GAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwAB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oGAFFK BgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhEgSEYSY/hXG BQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAAGRgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhI AAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY /k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABkYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgMAUUoDAF5KAwBvKACH aAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhAgHEYSY/hXGBQABCAcG XoQIB2CEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oDAFFKAwBe SgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4R4DxGEmP4V xgUAAXgPBl6EeA9ghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABUYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9K AwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E 6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAA AAAAAAAAaAEAAAAAAAAVGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKACHaAAA AACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhDgEEYSY/hXGBQABOAQGXoQ4 BGCEmP5PSgMAUUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA ABUYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAQBRSgEA bygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SoDBGEmP4VxgUA AagMBl6EqAxghJj+T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAAVGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oGAFFKBgBvKACHaAAAAACISAAA AQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5P SgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EGBUR hJj+FcYFAAEYFQZehBgVYISY/k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBgBRSgYAbygAh2gA AAAAiEgAAAEAp/ADAAAAu3OPaAAAAAAAAAAAAAAAAIA+BQwAAAAAAAAAAAAAAAAqLJQ1AAAAAAAA AAAAAAAA//////////////////8DAAAAAAAAAAAA//8DAAAAEgABAAkEAwAJBAUACQQBAAkEAwAJ BAUACQQBAAkEAwAJBAUACQQSAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEBgAAAAQAAAAIAAAA5QAAAAAAAAAF AAAA8UcWAIt7GQAEGDgAZzufANtYogClde0AAAAAAAIAAAAaEAAAHRAAAAAAAAA9oQIwAAAAAP9A A4ABABoQAAAaEAAAXOyQAAEAAAAaEAAAAAAAABoQAAAAAAAAAhAAAAAAAAAAGxAAAJAAABAAQAAA //8CAAAABwBVAG4AawBuAG8AdwBuAA0ARgBhAHIAaQBkACAAQQBkAHIAYQBuAGcAaQD//wIACAAA AAAAAAAAAAAAAAAAAAAAAAABAP//AgAAAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAHAAAA RxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMA eQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBp AGEAbAAAAD81kAEAAAIHAwkCAgUCBASHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkA ZQByACAATgBlAHcAAAA3FpABAAACBAUCBQQFAgMDhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAARwBl AG8AcgBnAGkAYQAAADUmkAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEA aABvAG0AYQAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBn AGQAaQBuAGcAcwAAACIABABBAIgYAPDQAgAAaAEAAAAArEWDJg9Yg4YAAAAABwAUAAAAZwIAALQN AAABAAgAAAAEAAMAHQAAAGcCAAC0DQAAAQAIAAAAHQAAAAAAAAA8JwDwEAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgQAABAAGQBkAAAAGQAAABMQAAATEAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA AAAAAAUzg0EA8BAA398AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAKPD/DwAAAT8A AOQEAAABAAAA////f////3////9/////f////3////9/8UcWAP//EgAAAAAAAAAVAFIAQQBEAEkA VQBTACAAQgBvAEYAIABhAHQAIABJAEUAVABGAC0ANQA5AAAAAAAAAA0ARgBhAHIAaQBkACAAQQBk AHIAYQBuAGcAaQANAEYAYQByAGkAZAAgAEEAZAByAGEAbgBnAGkAAAAAAAAAAAAAAAAAAAAAAAAA AAAYAAAABgAAAAMAAAAAAAwAAQAMAAIADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez 2TAAAAB4AQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAsAAAAAQAAAC8AAAABQAAANQAAAAHAAAA 4AAAAAgAAAD0AAAACQAAAAwBAAASAAAAGAEAAAoAAAA0AQAADAAAAEABAAANAAAATAEAAA4AAABY AQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAAAOQEAAAeAAAAFgAAAFJBRElVUyBCb0YgYXQg SUVURi01OQAxAB4AAAABAAAAAEFESR4AAAAOAAAARmFyaWQgQWRyYW5naQBJRR4AAAABAAAAAGFy aR4AAAALAAAATm9ybWFsLmRvdABnHgAAAA4AAABGYXJpZCBBZHJhbmdpAElFHgAAAAIAAAA3AHJp HgAAABQAAABNaWNyb3NvZnQgV29yZCAxMC4wAEAAAAAAeEHLAgAAAEAAAAAAeDPnoQXEAUAAAAAA 2nDyQAfEAQMAAAABAAAAAwAAAGcCAAADAAAAtA0AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAADAEA AAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAA rAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAO4AAAACAAAA5AQAAB4AAAAS AAAASW50ZWwgQ29ycG9yYXRpb24AIAADAAAAHQAAAAMAAAAIAAAAAwAAABMQAAADAAAArQ0KAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAWAAAAUkFESVVTIEJvRiBhdCBJ RVRGLTU5AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAAP7///8UAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA/v///xwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAD+////MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAAP7/ ///9////PAAAAP7////+/////v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////UgBv AG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAcOTa+UAHxAE+ AAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABMAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwAAAO8cAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJSQAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNX b3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0 ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABwfpwVQgfEAUQAAACA AwAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAA7xwAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlJAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAAR AAAAEgAAAP7///8UAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA/v///xwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAsAAAALQAA AC4AAAAvAAAAMAAAADEAAAD+//////////////////////////////////////////////////// /////////////////////0MAAAD9/////v////7////+////QgAAAP////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQAAAP7///8D AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8EAAAAQAEAAAUA AAB4AQAABAAAAAIAAAAUAAAAXwBBAGQASABvAGMAUgBlAHYAaQBlAHcAQwB5AGMAbABlAEkARAAA AAMAAAAOAAAAXwBFAG0AYQBpAGwAUwB1AGIAagBlAGMAdAAAAAQAAAANAAAAXwBBAHUAdABoAG8A cgBFAG0AYQBpAGwAAAAAAAUAAAAYAAAAXwBBAHUAdABoAG8AcgBFAG0AYQBpAGwARABpAHMAcABs AGEAeQBOAGEAbQBlAAAAAgAAALAEAAATAAAACQQAAAMAAAAMYoI0HwAAABYAAABSAEEARABJAFUA UwBFAHgAdAAgAEIAbwBGACAAbQBpAG4AdQB0AGUAcwAAAB8AAAAYAAAAZgBhAHIAaQBkAC4AYQBk AHIAYQBuAGcAaQBAAGkAbgB0AGUAbAAuAGMAbwBtAAAAHwAAAA8AAABBAGQAcgBhAG4AZwBpACwA IABGAGEAcgBpAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAUwB1AG0AbQBh AHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAQAAAA AAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAAA8AIAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD///// BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9j ABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4b EJOXCAArLPmuUAEAAAwBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAAAJQAAAARAAAA nAAAABcAAACkAAAACwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwAAADu AAAAAgAAAOQEAAAeAAAAEgAAAEludGVsIENvcnBvcmF0aW9uACAAAwAAAB0AAAADAAAACAAAAAMA AAATEAAAAwAAAK0NCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAFgAA AFJBRElVUyBCb0YgYXQgSUVURi01OQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAACgAQAA BwAAAAAAAABAAAAAAQAAAPQAAAAAAACA/AAAAAIAAAAEAQAAAwAAAAwBAAA= ------_=_NextPart_001_01C40742.171AA682-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 02 Mar 2004 01:39:14 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Cc: "'Adrangi, Farid'" , 'Parviz Yegani' Subject: RADIUS Bar BOF at Emerald Room Date: Mon, 1 Mar 2004 20:39:09 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:avi@bridgewatersystems.com] Sent: Tuesday, February 17, 2004 5:11 PM To: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 02 Mar 2004 01:34:48 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Cc: "'Adrangi, Farid'" , 'Parviz Yegani' Subject: Date: Mon, 1 Mar 2004 20:34:17 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:avi@bridgewatersystems.com] Sent: Tuesday, February 17, 2004 5:11 PM To: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: