Subject: AW: RADIUS BAR BOF in Korea
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 27 Feb 2004 10:13:55 +0100

>> I am Osok Song at Samsung Electronics, Korea. I am glad that you (and Farid) invited me to 
>> attend this BoF.

>> I found that the social event is planed to be on Tuesday evening. Would it be OK for the all >> attendee? (Personally I will not attend the social event.)  Also I want to know how many 
>> people are going to be at BoF.

> I'll be at the BOF. 

Me too

Wolfgang

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

Delivery-date: Fri, 27 Feb 2004 00:58:59 +0000
Date: Thu, 26 Feb 2004 16:58:03 -0800
To: Osok Song <[email-masked]>, "'Avi Lior'" <[email-masked]>, [email-masked]
From: Parviz Yegani <[email-masked]>
Subject: RE: RADIUS BAR BOF in Korea
Cc: "'Adrangi, Farid'" <[email-masked]>

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

At 09:25 AM 2/27/2004 +0900, Osok Song wrote:

>Hi all,
>
>
>
>I am Osok Song at Samsung Electronics, Korea. I am glad that you (and 
>Farid) invited me to attend this BoF.
>
>I found that the social event is planed to be on Tuesday evening. Would it 
>be OK for the all attendee? (Personally I will not attend the social 
>event.)  Also I want to know how many people are going to be at BoF.

I'll be at the BOF.

Rgds,
Parviz

>
>
>Regards,
>
>
>
>Osok
>
>
>
>===========================
>
>Osok Song
>
>Senior Engineer / Ph.D
>
>Global Standards & ResearchTeam
>
>Samsung Electronics Co., Ltd.
>
>===========================
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Avi Lior
>Sent: Friday, February 27, 2004 8:42 AM
>To: [email-masked]
>Cc: Adrangi, Farid; 'Parviz Yegani'
>Subject: RADIUS BAR BOF in Korea
>
>
>
>The best time for having a Bar BOF for RADIUS appears to be on Tuesday 
>evening after the last session of the Day.
>
>
>
>Tuesday at 18:30 location TBD.
>
>
>
>We dont know exactly where the best spot -- but we will post it to this list.
>
>
>
>Avi
>-----Original Message-----
>From: Avi Lior [mailto:[email-masked]]
>Sent: Tuesday, February 17, 2004 5:11 PM
>To: [email-masked]
>Subject: Who is planning to be in Korea?
>We would like to know who is planning to be in Korea.
>
>
>Perhaps we can get together one night for some beer.
>
>
>
>
>Avi.

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

<html>
At 09:25 AM 2/27/2004 +0900, Osok Song wrote:<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#000080">Hi
all,<br>
</font><br>
<font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>
<font face="arial" size=2 color="#000080">I am Osok Song at Samsung
Electronics, Korea. I am glad that you (and Farid) invited me to attend
this BoF.<br>
</font><br>
<font face="arial" size=2 color="#000080">I found that the social event
is planed to be on Tuesday evening. Would it be OK for the all attendee?
(Personally I will not attend the social event.)&nbsp; Also I want to
know how many people are going to be at BoF.</font></blockquote><br>
I'll be at the BOF. <br>
<br>
Rgds,<br>
Parviz<br>
<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>
<font face="arial" size=2 color="#000080">Regards,<br>
</font><br>
<font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>
<font face="arial" size=2 color="#000080">Osok<br>
</font><br>
<font size=2 color="#000080">&nbsp;<br>
</font><br>
<font face="arial" size=2 color="#000080">===========================&nbsp;&nbsp;
<br>
</font><br>
<font face="arial" size=2 color="#000080">Osok Song&nbsp;&nbsp; <br>
</font><br>
<font face="arial" size=2 color="#000080">Senior Engineer /
Ph.D&nbsp;&nbsp; <br>
</font><br>
<font face="arial" size=2 color="#000080">Global Standards &amp;
ResearchTeam&nbsp;&nbsp; <br>
</font><br>
<font face="arial" size=2 color="#000080">Samsung Electronics Co.,
Ltd.&nbsp;&nbsp; <br>
</font><br>
<font face="arial" size=2 color="#000080">===========================<br>
</font><br>
<font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Avi Lior<br>
<b>Sent:</b> Friday, February 27, 2004 8:42 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> Adrangi, Farid; 'Parviz Yegani'<br>
<b>Subject:</b> RADIUS BAR BOF in Korea<br>
</font><br>
&nbsp;<br>
<br>
<font face="arial" size=2 color="#0000FF">The best time for having a Bar
BOF for RADIUS appears to be on Tuesday evening after the last session of
the Day.<br>
</font><br>
&nbsp;<br>
<br>
<font face="arial" size=2 color="#0000FF">Tuesday at 18:30 location
TBD.<br>
</font><br>
&nbsp;<br>
<br>
<font face="arial" size=2 color="#0000FF">We dont know exactly where the
best spot -- but we will post it to this list.<br>
</font><br>
&nbsp;<br>
<br>
<font face="arial" size=2 color="#0000FF">Avi</font>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Avi Lior
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>] 
<dd>Sent:</b> Tuesday, February 17, 2004 5:11 PM
<dd>To:</b> [email-masked]
<dd>Subject:</b> Who is planning to be in
Korea?</font><font face="arial" size=2>
<dd>We would like to know who is planning to be in Korea.</font>
<dd>&nbsp;<br>
<br>
<font face="arial" size=2>
<dd>Perhaps we can get together one night for some beer.&nbsp; </font>
<dd>&nbsp;<br>
<br>

<dd>&nbsp;<br>
<br>
<font face="arial" size=2>
<dd>Avi.</font>
</dl></blockquote></html>

--=====================_107766349==_.ALT--

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

Delivery-date: Fri, 27 Feb 2004 00:28:21 +0000
Date: Fri, 27 Feb 2004 09:25:11 +0900
From: Osok Song <[email-masked]>
Subject: RE: RADIUS BAR BOF in Korea
To: 'Avi Lior' <[email-masked]>, [email-masked]
Cc: "'Adrangi, Farid'" <[email-masked]>, 'Parviz Yegani' <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_LeleFyX++XdNbjVMcv3WCA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi all,
 
I am Osok Song at Samsung Electronics, Korea. I am glad that you (and
Farid) invited me to attend this BoF.
I found that the social event is planed to be on Tuesday evening. Would
it be OK for the all attendee? (Personally I will not attend the social
event.)  Also I want to know how many people are going to be at BoF.
 
Regards,
 
Osok
 
===========================   
Osok Song   
Senior Engineer / Ph.D   
Global Standards & ResearchTeam   
Samsung Electronics Co., Ltd.   
===========================
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Friday, February 27, 2004 8:42 AM
To: [email-masked]
Cc: Adrangi, Farid; 'Parviz Yegani'
Subject: RADIUS BAR BOF in Korea
 
The best time for having a Bar BOF for RADIUS appears to be on Tuesday
evening after the last session of the Day.
 
Tuesday at 18:30 location TBD.
 
We dont know exactly where the best spot -- but we will post it to this
list.
 
Avi
-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2004 5:11 PM
To: [email-masked]
Subject: Who is planning to be in Korea?
We would like to know who is planning to be in Korea.
 
Perhaps we can get together one night for some beer.  

Avi.

--Boundary_(ID_LeleFyX++XdNbjVMcv3WCA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 10">
<meta name=Originator content="Microsoft Word 10">
<link rel=File-List href="cid:[email-masked]">
<title>Message</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="time"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="date"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName" downloadurl="http://www.microsoft.com"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-alt:Batang;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:Gulim;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:modern;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Gulim;
	mso-ascii-font-family:Gulim;
	mso-fareast-font-family:Gulim;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	mso-header-margin:42.55pt;
	mso-footer-margin:49.6pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 table.MsoNormalTable
	{mso-style-name:"\D45C\C900 \D45C";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=KO link=blue vlink=purple style='tab-interval:40.0pt'>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>Hi all,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>I am Osok Song at Samsung
Electronics, Korea. I am glad that you (and Farid) invited me to attend this <span
class=SpellE>BoF</span>.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>I found that the social event
is planed to be on Tuesday evening. Would it be OK for the all attendee?
(Personally I will not attend the social event.)<span
style='mso-spacerun:yes'>&nbsp; </span>Also I want to know how many people are
going to be at <span class=SpellE>BoF</span>.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy'>Osok<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=&#44404;&#47548;><span
lang=EN-US style='font-size:10.0pt;mso-hansi-font-family:Arial;mso-bidi-font-family:
Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>===========================&nbsp;&nbsp;
</span></font><font color=navy><span lang=EN-US style='color:navy;mso-no-proof:
yes'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Osok
Song&nbsp;&nbsp; </span></font><font color=navy><span lang=EN-US
style='color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Senior
Engineer / Ph.D&nbsp;&nbsp; </span></font><font color=navy><span lang=EN-US
style='color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Global
Standards &amp; ResearchTeam&nbsp;&nbsp; </span></font><font color=navy><span
lang=EN-US style='color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Samsung
Electronics Co., Ltd.&nbsp;&nbsp; </span></font><font color=navy><span
lang=EN-US style='color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>===========================</span></font><span
lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> [email-masked]
[mailto:[email-masked]] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Avi Lior<br>
<b><span style='font-weight:bold'>Sent:</span></b> </span></font><st1:date
Month="2" Day="27" Year="2004"><font size=2 face=Tahoma><span lang=EN-US
 style='font-size:10.0pt;font-family:Tahoma'>Friday, February 27, 2004</span></font></st1:date><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
</span></font><st1:time Hour="8" Minute="42"><font size=2 face=Tahoma><span
 lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>8:42 AM</span></font></st1:time><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Cc:</span></b> </span></font><st1:PersonName><font
 size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>Adrangi,
 Farid</span></font></st1:PersonName><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma'>; 'Parviz Yegani'<br>
<b><span style='font-weight:bold'>Subject:</span></b> RADIUS BAR BOF in </span></font><st1:country-region><st1:place><font
  size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>Korea</span></font></st1:place></st1:country-region></p>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 color=blue face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial;color:blue'>The best time for having a Bar BOF for RADIUS
appears to be on Tuesday evening after the last session of the Day.</span></font><span
lang=EN-US><o:p></o:p></span></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 color=blue face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial;color:blue'>Tuesday at </span></font><st1:time Hour="18"
Minute="30"><font size=2 color=blue face=Arial><span lang=EN-US
 style='font-size:10.0pt;font-family:Arial;color:blue'>18:30</span></font></st1:time><font
size=2 color=blue face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial;color:blue'> location TBD.</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 color=blue face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial;color:blue'>We dont know exactly where the best spot -- but
we will post it to this list.</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 color=blue face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial;color:blue'>Avi</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<blockquote style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:39.95pt;mso-margin-top-alt:0cm;mso-para-margin-right:0cm;
mso-para-margin-bottom:12.0pt;mso-para-margin-left:3.33gd'><font size=2
face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Avi Lior
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> </span></font><st1:date
Month="2" Day="17" Year="2004"><font size=2 face=Tahoma><span lang=EN-US
 style='font-size:10.0pt;font-family:Tahoma'>Tuesday, February 17, 2004</span></font></st1:date><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
</span></font><st1:time Hour="17" Minute="11"><font size=2 face=Tahoma><span
 lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>5:11 PM</span></font></st1:time><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Who is planning to be in </span></font><st1:country-region><st1:place><font
  size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>Korea</span></font></st1:place></st1:country-region><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>?</span></font><span
lang=EN-US><o:p></o:p></span></p>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:Arial'>We
would like to know who is planning to be in </span></font><st1:country-region><st1:place><font
  size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:Arial'>Korea</span></font></st1:place></st1:country-region><font
size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:Arial'>.</span></font><span
lang=EN-US><o:p></o:p></span></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:Arial'>Perhaps
we can get together one night for some beer.&nbsp; </span></font><span
lang=EN-US><o:p></o:p></span></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=3 face=&#44404;&#47548;><span lang=EN-US style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:39.95pt;mso-para-margin-left:3.33gd'><font
size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:Arial'>Avi.</span></font><span
lang=EN-US><o:p></o:p></span></p>

</div>

</blockquote>

</div>

</body>

</html>

--Boundary_(ID_LeleFyX++XdNbjVMcv3WCA)--

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

Delivery-date: Thu, 26 Feb 2004 23:43:40 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Cc: "Adrangi, Farid" <[email-masked]>, 'Parviz Yegani' <[email-masked]>
Subject: RADIUS BAR BOF in Korea
Date: Thu, 26 Feb 2004 18:42:11 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3FCC2.2767E0C0
Content-Type: text/plain

The best time for having a Bar BOF for RADIUS appears to be on Tuesday
evening after the last session of the Day.
 
Tuesday at 18:30 location TBD.
 
We dont know exactly where the best spot -- but we will post it to this
list.
 
Avi

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2004 5:11 PM
To: [email-masked]
Subject: Who is planning to be in Korea?

We would like to know who is planning to be in Korea.
 
Perhaps we can get together one night for some beer.  

Avi.

------_=_NextPart_001_01C3FCC2.2767E0C0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=524032423-26022004>The 
best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after 
the last session of the Day.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=524032423-26022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=524032423-26022004>Tuesday at 18:30 location TBD.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=524032423-26022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=524032423-26022004>We 
dont know exactly where the best spot -- but we will post it to this 
list.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=524032423-26022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=524032423-26022004>Avi</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Avi Lior 
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, February 17, 
  2004 5:11 PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Who is 
  planning to be in Korea?<BR><BR></FONT></DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial size=2>We would like to 
  know who is planning to be in Korea.</FONT></SPAN></DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial size=2>Perhaps we can get 
  together one night for some beer.&nbsp; </FONT></SPAN></DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=468480922-17022004><FONT face=Arial 
  size=2>Avi.</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3FCC2.2767E0C0--

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

Delivery-date: Mon, 23 Feb 2004 21:50:29 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: New RADIUS Redirection Draft
Date: Mon, 23 Feb 2004 16:49:42 -0500

FYI: would appreciate comments on this work.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title : Remote Authentication Dial In User Service (RADIUS) Redirection
Author(s) : A. Lior
Filename : draft-lior-radius-redirection-00.txt
Pages : 27
Date : 2004-2-9

In certain scenarios there needs to be a method to force the users
traffic to a specific location. This document describes several
methods that are available to be used with Remote Authentication Dial
In User Service (RADIUS) Protocol and defines three new RADIUS
attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

This work has been motivated by PWLAN.

This draft introduces 3 new attributes and was written such that it
compliments Diameter.
NAS-Filter-Rule was introduced to make Filter-Id more roaming friendly (See
commentary in NASREQ)
Redirect-Id attribute is to be used like Filter-Id in those cases where
there is a 'tight' relationship with the roaming partners. Like Filter-Id,
Redirect-Id is not roaming friendly and hence we introduced Redirect-Rule.

Redirect-Rule is based on IPFW syntax slightly modified to implement
redirection. Again this approach is entirely consistant with Diameter's
approach for IPFilterRule.

However, IPFW does not support redirection. It does support (in some cases)
Forwarding but forwarding is not the same as Redirection.

Redirection has also been addressed by Diameter-Credit-Control Application.
However, in credit control redirection is done as a subset of the method
proposed here.

============================================
STATEMENT of Compliance to Proposed Charter 
============================================
The draft is 100% compatible with the RADIUS EXT Proposed Charter

Item 1: All work MUST be backward compatible with exiting RADIUS RFCs.
This draft is 100% backwards compatible with existing RADIUS RFCs.

Item 2: No new RADIUS transports
No new transports were introdcued.

Item 3: No changes will be considered to the RADIUS attribute format.
No changes were made to any RADIUS attribute format. The new attriutes are
of type STRING.

Item 4: No new RADIUS data types will be defined.
No new RADIUS data type was introduced.

Item 5: The RADIUS maximum packet size (4K) will not be increaded.
Packet size remains less the 4K.

Item 6: No RADIUS attribute "sub-types" will be defined.
No new attribute called "sub-types" was defined or introduced. All
attributes are based on existing RADIUS types.

Item 7: No new RADIUS secuirty mechanism will be defined.
No new security mechanisms was introduced.

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

Delivery-date: Fri, 20 Feb 2004 04:58:47 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: New Prepaid Draf version 3 is now available.
Date: Thu, 19 Feb 2004 23:58:30 -0500

The draft is available
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-03.
txt 

Whats new:

Formalized the required set of attributes -- there are three attributes.
Addes discussion on why the the prepaid approach in this document is more
robust then doing prepaid using existing RADIUS attributes.

There is already a version 4 in the works......

============================================
STATEMENT of Compliance to Proposed Charter
============================================

The draft is 100% compatible with the RADIUS EXT Proposed Charter

Item 1:  All work MUST be backward compatible with exiting RADIUS RFCs.

This draft is 100% backwards compatible with existing RADIUS RFCs.

Item 2: No new RADIUS transports

No new transports were introdcued.

Item 3:  No changes will be considered to the RADIUS attribute format.

No changes were made to any RADIUS attribute format.  The new attriutes are
of type STRING.

Item 4: No new RADIUS data types will be defined.

No new RADIUS  data type was introduced.

Item 5: The RADIUS maximum packet size (4K) will not be increaded.

Packet size remains less the 4K.

Item 6: No RADIUS attribute "sub-types" will be defined.

No new attribute called "sub-types" was defined or introduced.  All
attributes are based on RADIUS type STRING.

Item 7: No new RADIUS secuirty mechanism will be defined.

No new security mechanisms was introduced.

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

Delivery-date: Thu, 19 Feb 2004 18:49:00 +0000
Date: Thu, 19 Feb 2004 10:47:41 -0800
From: "Murtaza S. Chiba" <[email-masked]>
To: Avi Lior <[email-masked]>
CC: [email-masked]
Subject: Re: Query requests

Hey Avi,
	Great we are on the same wavelength!  Location is one of the 
parameters, I was thinking more in terms of services enabled for the user.

Regards,
Murtaza

Avi Lior wrote:
> Hi Murtaza,
> 
> It probably is out of charter.  Two things:
> 
> 1) Just yesterday while working on location I was wondering if we could use
> AAA to pull position information from the NAS which perhaps can go to the
> client as well.
> 
> 2) In 3GPP2 we decided that Network Presence would be delivered to the
> Presence Server via AAA (RADIUS).  It is conceivable that the Presence
> Server may want to query the AAA for Network Presence Information.
> 
> So your "wondering" is intriguing me.
> 
> Avi
> 
> 
>>-----Original Message-----
>>From: Murtaza S. Chiba [mailto:[email-masked]] 
>>Sent: February 18, 2004 7:18 PM
>>To: [email-masked]
>>Subject: Query requests
>>
>>
>>Probably out of the charter.  But was wondering if any 
>>thought was given 
>>for Query requests that would return status of current session/s for 
>>self-care type applications.  The dynamic-author interface could be 
>>extended.
>>
>>
>>Thanks,
>>Murtaza
>>
>>--
>>to unsubscribe send a message to 
>>[email-masked] with the word 'unsubscribe' in 
>>a single line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>
> 

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

Delivery-date: Thu, 19 Feb 2004 14:44:55 +0000
From: Avi Lior <[email-masked]>
To: "'Murtaza S. Chiba'" <[email-masked]>, [email-masked]
Subject: RE: Query requests
Date: Thu, 19 Feb 2004 09:44:34 -0500

Hi Murtaza,

It probably is out of charter.  Two things:

1) Just yesterday while working on location I was wondering if we could use
AAA to pull position information from the NAS which perhaps can go to the
client as well.

2) In 3GPP2 we decided that Network Presence would be delivered to the
Presence Server via AAA (RADIUS).  It is conceivable that the Presence
Server may want to query the AAA for Network Presence Information.

So your "wondering" is intriguing me.

Avi

> -----Original Message-----
> From: Murtaza S. Chiba [mailto:[email-masked]] 
> Sent: February 18, 2004 7:18 PM
> To: [email-masked]
> Subject: Query requests
> 
> 
> Probably out of the charter.  But was wondering if any 
> thought was given 
> for Query requests that would return status of current session/s for 
> self-care type applications.  The dynamic-author interface could be 
> extended.
> 
> 
> Thanks,
> Murtaza
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 19 Feb 2004 00:19:07 +0000
Date: Wed, 18 Feb 2004 16:17:51 -0800
From: "Murtaza S. Chiba" <[email-masked]>
To: [email-masked]
Subject: Query requests

Probably out of the charter.  But was wondering if any thought was given 
for Query requests that would return status of current session/s for 
self-care type applications.  The dynamic-author interface could be 
extended.

Thanks,
Murtaza

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

Delivery-date: Wed, 18 Feb 2004 15:51:18 +0000
Date: Wed, 18 Feb 2004 08:02:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: RADIUS Location Drafts

Any draft involving location information is covered.  This includes both
the Jones and Adrangi drafts.

On Wed, 18 Feb 2004, Avi Lior wrote:

> Bernard,
>
> I need some clarification.  Does that mean just the jones draft or both the
> jones draft and the adrangi draft?
>
> Avi

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

Delivery-date: Wed, 18 Feb 2004 13:35:09 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: RADIUS Location Drafts
Date: Wed, 18 Feb 2004 08:34:51 -0500

Bernard,

I need some clarification.  Does that mean just the jones draft or both the
jones draft and the adrangi draft?

Avi

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: February 18, 2004 3:22 AM
> To: [email-masked]
> Subject: RADIUS Location Drafts
> 
> 
> We have discussed the issue of RADIUS location attributes 
> with the GEOPRIV WG chairs, and they have made a request that 
> this work be discussed with them, rather than being handled in RADEXT.
> 
> Therefore at this point, the discussion on RADIUS location 
> attributes should move to the GEOPRIV mailing list.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Wed, 18 Feb 2004 11:11:45 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Mark Grayson (mgrayson)'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: AW: "service-key" in  Lior-Draft ( Radius-Prepaid-Extension)
Date: Wed, 18 Feb 2004 11:11:15 -0000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3F60F.ED047802
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Mark,
=20
thanks for the link - unfortunately I could not locate any appearance =
of the
term "service-identifier" in the document.=20
Could you please be more specific or provide a link to the Diameter =
document
that contains the term "service-identifier" you are talking about.
=20
Or do you mean the term  "charging key" as being equivalent/analogous  =
to
"service key"  / "service identifier" ?
=20
Many thanks in advance.
=20
Lothar

-----Urspr=FCngliche Nachricht-----
Von: Mark Grayson (mgrayson) [mailto:[email-masked]]=20
Gesendet: Dienstag, 17. Februar 2004 18:33
An: Reith, Lothar [HAHN:ND:EXCH]; Avi Lior; [email-masked]
Betreff: RE: "service-key" in Lior-Draft ( Radius-Prepaid-Extension)

Lothar
=20
as I understand it, service key is analagous to the service-identifier =
in
Diameter Credit Control and is being specified by other standardzation
bodies, e.g., 3GPP
(http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip
<http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip> =
)
which then assists in rating the pre-paid request.
=20
Cheers,
Mark
=20

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]] On
Behalf Of Lothar Reith
Sent: 17 February 2004 16:07
To: 'Avi Lior'; [email-masked]
Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension)

Ladies and Gentlemen,=20

I would like to comment on the RADIUS-Prepaid-Extension Draft.=20

It contains the statement:=20

"The exact definition of these services is not the focus of this draft.
This=20
   definition MAY include a "service key" which can be used to=20
   correlate prepaid requests for access to a service with the service=20
   definition in the prepaid system."=20

Can someone please shed some light on why the concept of "service key" =
is
being introduced.=20

If I understand correctly, the whole draft is about some prepaid-server
(sometimes also referred to as Quota-Server - or what is the difference
between a Quota-Server and a Prepaid Server?) that MAY be part of a =
RADIUS
Server. Okay, if the prepaid server IS part of a RADIUS server, then =
perhaps
no issue, the Service-Key is just another Attribute but I do not =
understand
what it is good for in this case.

In the more interesting case, where the Quota-Server (or Prepaid =
Server) is
not part of the AAA Server, the question arises to me, if the =
Service-Key is
not a trojan-horse that actually deprives the AAA Server from its =
original
task of service authorization. If I understand the draft correctly, =
then the
service-key identifies a bundle of a number of primitive services to =
which
the user has subscribed, hence it belongs into the AAA-Server and not =
into
the Quota Server. And by the way, watch out for the definiton of the =
term
"service" - it is not identical to the definition of "service" in the =
base
RADIUS RFC.

Is this service subscription information not something which =
architecturally
belongs into the the AAA Server and not into the Prepaid-Server ?=20

If we start splitting user subscription data over 2 databases (RADIUS =
Server
and Prepaid Server) things become very messy. Is it design intend of =
that
draft that the RADIUS Server becomes "transparent" and the =
Prepaid-Server
takes over ?

Put perhaps somebody can enlight me about the wisdom of introducing the
"service key" concept into this draft (which does not seem to be =
included in
the related 3GPP2 work on PrePaid Data Service).

I had thought, that the task of a Quota-Server is to manage Quotas, and =
not
authorize services.=20

my 2 Milli-Euro...=20

Lothar=20

------_=_NextPart_001_01C3F60F.ED047802
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE>Nachricht</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Mark,</FONT></SPAN></DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff size=3D2>thanks=20
for the link - unfortunately I could not locate any appearance of the =
term=20
"service-identifier" in the document. </FONT></SPAN></DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff size=3D2>Could=20
you please be more specific or provide a link to the Diameter document =
that=20
contains the term&nbsp;"service-identifier" you are talking=20
about.</FONT></SPAN></DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff size=3D2>Or do=20
you mean the term &nbsp;"charging key" as being equivalent/analogous =
&nbsp;to=20
"service key"&nbsp; / "service identifier" ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff size=3D2>Many=20
thanks in advance.</FONT></SPAN></DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D449595110-18022004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Lothar</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Urspr=FCngliche Nachricht-----<BR><B>Von:</B> Mark =
Grayson=20
  (mgrayson) [mailto:[email-masked]] <BR><B>Gesendet:</B> Dienstag, =
17.=20
  Februar 2004 18:33<BR><B>An:</B> Reith, Lothar [HAHN:ND:EXCH]; Avi =
Lior;=20
  [email-masked]<BR><B>Betreff:</B> RE: "service-key" in =
Lior-Draft (=20
  Radius-Prepaid-Extension)<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004>Lothar</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D439362217-17022004>as I=20
  understand it, service key is analagous to the service-identifier in =
Diameter=20
  Credit Control and is being specified by other standardzation bodies, =
e.g.,=20
  3GPP (<A=20
  =
href=3D"http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140=
.zip">http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.=
zip</A>)=20
  which then assists in rating the pre-paid =
request.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004>Cheers,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004>Mark</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Lothar Reith<BR><B>Sent:</B> 17 February 2004=20
    16:07<BR><B>To:</B> 'Avi Lior'; =
[email-masked]<BR><B>Subject:</B>=20
    "service-key" in Lior-Draft ( =
Radius-Prepaid-Extension)<BR><BR></FONT></DIV>
    <P><FONT size=3D2>Ladies and Gentlemen,</FONT> </P>
    <P><FONT size=3D2>I would like to comment on the =
RADIUS-Prepaid-Extension=20
    Draft.</FONT> </P>
    <P><FONT size=3D2>It contains the statement:</FONT> </P>
    <P><FONT size=3D2>"The exact definition of these services is not =
the focus of=20
    this draft.&nbsp; This </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
definition MAY=20
    include a "service key" which can be used to </FONT><BR><FONT=20
    size=3D2>&nbsp;&nbsp; correlate prepaid requests for access to a =
service with=20
    the service </FONT><BR><FONT size=3D2>&nbsp;&nbsp; definition in =
the prepaid=20
    system."</FONT> </P>
    <P><FONT size=3D2>Can someone please shed some light on why the =
concept of=20
    "service key" is being introduced. </FONT></P>
    <P><FONT size=3D2>If I understand correctly, the whole draft is =
about some=20
    prepaid-server (sometimes also referred to as Quota-Server - or =
what is the=20
    difference between a Quota-Server and a Prepaid Server?) that MAY =
be part of=20
    a RADIUS Server. Okay, if the prepaid server IS part of a RADIUS =
server,=20
    then perhaps no issue, the Service-Key is just another Attribute =
but I do=20
    not understand what it is good for in this case.</FONT></P>
    <P><FONT size=3D2>In the more interesting case, where the =
Quota-Server (or=20
    Prepaid Server) is not part of the AAA Server, the question arises =
to me, if=20
    the Service-Key is not a trojan-horse that actually deprives the =
AAA Server=20
    from its original task of service authorization. If I understand =
the draft=20
    correctly, then the service-key identifies a bundle of a number of =
primitive=20
    services to which the user has subscribed, hence it belongs into =
the=20
    AAA-Server and not into the Quota Server. And by the way, watch out =
for the=20
    definiton of the term "service" - it is not identical to the =
definition of=20
    "service" in the base RADIUS RFC.</FONT></P>
    <P><FONT size=3D2>Is this service subscription information not =
something which=20
    architecturally belongs into the the AAA Server and not into the=20
    Prepaid-Server ? </FONT></P>
    <P><FONT size=3D2>If we start splitting user subscription data over =
2=20
    databases (RADIUS Server and Prepaid Server) things become very =
messy. Is it=20
    design intend of that draft that the RADIUS Server becomes =
"transparent" and=20
    the Prepaid-Server takes over ?</FONT></P>
    <P><FONT size=3D2>Put perhaps somebody can enlight me about the =
wisdom of=20
    introducing the "service key" concept into this draft (which does =
not seem=20
    to be included in the related 3GPP2 work on PrePaid Data=20
Service).</FONT></P>
    <P><FONT size=3D2>I had thought, that the task of a Quota-Server is =
to manage=20
    Quotas, and not authorize services.</FONT> </P>
    <P><FONT size=3D2>my 2 Milli-Euro...</FONT> </P>
    <P><FONT size=3D2>Lothar</FONT> </P><BR><BR>
    <P><FONT =
size=3D2></FONT></P><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3F60F.ED047802--

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

Delivery-date: Wed, 18 Feb 2004 08:10:17 +0000
Date: Wed, 18 Feb 2004 00:21:38 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADIUS Location Drafts

We have discussed the issue of RADIUS location attributes with the GEOPRIV
WG chairs, and they have made a request that this work be discussed with
them, rather than being handled in RADEXT.

Therefore at this point, the discussion on RADIUS location attributes
should move to the GEOPRIV mailing list.

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

Delivery-date: Tue, 17 Feb 2004 22:39:34 +0000
Content-Class: urn:content-classes:message
Subject: RE: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 14:38:03 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Mark Grayson (mgrayson)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "John Schnizlein (jschnizl)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Mark,
Not yet!  As you know, we are trying to reach consensus whether UserName
(1) rewrite will be sufficient or there is a need for the new attribute
(currently discussed in GSMA).  There has been couple of
clarification-related questions posted on eap WG on RFC 3579 -- but we
haven't got any answers from the authors yet.=20
BR,
Farid

> -----Original Message-----
> From: Mark Grayson (mgrayson) [mailto:[email-masked]]=20
> Sent: Tuesday, February 17, 2004 2:09 PM
> To: Adrangi, Farid; [email-masked];=20
> [email-masked];=20
> [email-masked]; John Schnizlein (jschnizl)
> Cc: [email-masked]; [email-masked]
> Subject: RE: RE: RE: RE: draft-jones-radius-geopriv
>=20
>=20
> Farid
>=20
> Is the chargeable identity draft available?
>=20
> Cheers,
> Mark
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of Adrangi,=20
> Farid
> Sent: 17 February 2004 21:11
> To: [email-masked]; [email-masked];
> [email-masked]; John Schnizlein (jschnizl)
> Cc: [email-masked]; [email-masked]
> Subject: RE: RE: RE: RE: draft-jones-radius-geopriv
>=20
>=20
>=20
> > Is there any chance that the GSMA could bring their requirements
> > to the IETF, so that we can ensure we don't have too many
> > conflicting requirements & also have a chance to understand
> > what are the real requirements?  I know the IETF has had=20
> > misunderstandings
> > in the past with respect to 3GPP requirements.
> >=20
>=20
> [FA] Yes.  Actually, I believe Jouni K. has already sent an=20
> LS from GSMA
> to IETF (Bernard / David Nelson) on this. =20
>=20
> BR,
> Farid
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 17 Feb 2004 22:11:30 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Who is planning to be in Korea?
Date: Tue, 17 Feb 2004 17:11:21 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3F5A2.F94CE8A0
Content-Type: text/plain

We would like to know who is planning to be in Korea.
 
Perhaps we can get together one night for some beer.  

Avi.

------_=_NextPart_001_01C3F5A2.F94CE8A0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=468480922-17022004><FONT face=Arial size=2>We would like to 
know who is planning to be in Korea.</FONT></SPAN></DIV>
<DIV><SPAN class=468480922-17022004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=468480922-17022004><FONT face=Arial size=2>Perhaps we can get 
together one night for some beer.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=468480922-17022004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=468480922-17022004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=468480922-17022004><FONT face=Arial 
size=2>Avi.</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C3F5A2.F94CE8A0--

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

Delivery-date: Tue, 17 Feb 2004 22:09:33 +0000
Content-Class: urn:content-classes:message
Subject: RE: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 23:08:47 +0100
From: "Mark Grayson (mgrayson)" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "John Schnizlein (jschnizl)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Farid

Is the chargeable identity draft available?

Cheers,
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adrangi, Farid
Sent: 17 February 2004 21:11
To: [email-masked]; [email-masked];
[email-masked]; John Schnizlein (jschnizl)
Cc: [email-masked]; [email-masked]
Subject: RE: RE: RE: RE: draft-jones-radius-geopriv

> Is there any chance that the GSMA could bring their requirements
> to the IETF, so that we can ensure we don't have too many
> conflicting requirements & also have a chance to understand
> what are the real requirements?  I know the IETF has had=20
> misunderstandings
> in the past with respect to 3GPP requirements.
>=20

[FA] Yes.  Actually, I believe Jouni K. has already sent an LS from GSMA
to IETF (Bernard / David Nelson) on this. =20

BR,
Farid

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

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

Delivery-date: Tue, 17 Feb 2004 21:56:51 +0000
Date: Tue, 17 Feb 2004 14:07:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: RE: RE: draft-jones-radius-geopriv

> [FA] Yes. We need to work with Mark Jones and others to make sure that we don't reinvent the wheels.

Yes.  A single draft that is parsimonious and compatible with existing
work (such as the DHCP option) would be helpful.

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

Delivery-date: Tue, 17 Feb 2004 21:12:02 +0000
Content-Class: urn:content-classes:message
Subject: RE: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 13:10:55 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

> Is there any chance that the GSMA could bring their requirements
> to the IETF, so that we can ensure we don't have too many
> conflicting requirements & also have a chance to understand
> what are the real requirements?  I know the IETF has had=20
> misunderstandings
> in the past with respect to 3GPP requirements.
>=20

[FA] Yes.  Actually, I believe Jouni K. has already sent an LS from GSMA
to IETF (Bernard / David Nelson) on this. =20

BR,
Farid

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

Delivery-date: Tue, 17 Feb 2004 20:41:58 +0000
content-class: urn:content-classes:message
Subject: GSMA requirements (was RE: draft-jones-radius-geopriv)
Date: Tue, 17 Feb 2004 15:41:49 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

John Loughney writes...

> Is there any chance that the GSMA could bring their requirements
> to the IETF, so that we can ensure we don't have too many
> conflicting requirements & also have a chance to understand
> what are the real requirements?

GSAM has just yesterday sent a Liaison Letter to the chairs.  It is not
as explicit in terms of requirements as one might like, however it is a
start.  Since distribution of this document is open to the IETF
community, I have reproduced the text of that letter here.

-- Dave

<quote>

To: 		RADEXT Working Group Chairs,=20
Bernard Aboba, [email-masked]
David Nelson, [email-masked]=20
From:	GSMA WLAN Task Force, Chairman, Carlo Cassisa,
[email-masked]
Director, Graham Trickey, [email-masked]
CC:	=09
Subject:	RADEXT new attributes for global WLAN Roaming
Date: 		14-Feb-2004
=20
Response date due by: Latest 8-Mar-2004

Background:
In recent developments of establishing a global SIM based inter-operator
WLAN roaming within GSMA WLAN TF, we have faced several challenges with
current RADIUS protocol. These challenges are mostly related to global
inter-operator location based billing and taxation issues and user
billing identities that are suitable for globally well established
inter-operator billing systems. After careful studies and live tests we
feel that there is room for enhancements in current RADIUS protocol to
satisfy our requirements for global inter-operator SIM based WLAN
roaming. These are needed to avoid fragmentation in inter-operator
billing system interfaces and ease the integration to existing global
inter-operator billing systems.

GMSA WLAN Task Force would like to state their interest in the work done
in IETF RADEXT Working Group identifying new RADIUS attributes and
clarifying the usage of existing RADIUS attributes (such as the
User-name attribute) that are usable for global SIM based WLAN roaming
purposes. These attributes and clarifications include location
information that is accurate enough for global billing and taxation
purposes and billable user identities that are also usable for well
established global inter-operator billing systems.

We would like to point out few ongoing drafts that deal with the issues
of our concern:
draft-adrangi-radiusext-location-information and
draft-adrangi-radius-chargeable-user-identity-attribute

The following drafts have also been identified useful in a global
roaming point of view:
draft-adrangi-radius-bandwidth-capability and
draft-lior-radius-redirection

In the near future we also see RADIUS and DIAMETER migration and
interworking as a challenge that should be solved in a proper way.

Actions:
GSMA WLAN TF is having their next meeting 11-Mar-2004 and we kindly ask
for an input from RADEXT Working Group chairs on how they see the
importance of adding attributes to the RADIUS protocol and/or clarifying
the use of existing attributes in order to ease the deployment of global
SIM based WLAN roaming.

<end-quote>

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

Delivery-date: Tue, 17 Feb 2004 20:31:54 +0000
content-class: urn:content-classes:message
Subject: RE:  RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 22:29:20 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Farid,

> > Having been through a similar exercize before, I don't much like the =
naming conventions
> > in the above draft - section 2.2 for example.=20
>=20
> [FA] Can you be more specific.  We would be more than happy=20
> to use your suggestions and advice in improving the naming=20
> convention and other things in the draft.

I'll re-read the document tomorrow & send some coments.
=20
> > Also, there are some editing nits, for example the '=C6'=20
> character in section 8. =20
>=20
> [FA] Good catch -- I thought I fixed that!
>=20
>=20
> > I'd prefer re-use of the work done in GEOPRIV.
>=20
> [FA] Yes. We need to work with Mark Jones and others to make=20
> sure that we don't reinvent the wheels.

Good.=20

> > Would you be looking at only access, or service specific=20
> issues as well?
> > How does it map to the GEOPRIV deliverables - for example=20
> the SIP & HTTP
> > drafts?=20
>=20
> [FA] right now, GSMA requirements are for location-based=20
> access and accounting.  We are also looking at location-based=20
> services, however we need to figure out how it maps to the=20
> GEOPPRIV deliverables as you pointed out.

Is there any chance that the GSMA could bring their requirements
to the IETF, so that we can ensure we don't have too many
conflicting requirements & also have a chance to understand
what are the real requirements?  I know the IETF has had =
misunderstandings
in the past with respect to 3GPP requirements.

thanks,
John

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

Delivery-date: Tue, 17 Feb 2004 20:31:24 +0000
content-class: urn:content-classes:message
Subject: RE:  RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 22:30:54 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Dave,

> John Loughney writes...
> > > This type of location information needs to be transported to the =
home
> > > network and must only be used for that intention.
> >=20
> > How does one guarantee that?
>=20
> I wonder if it is ever possible to guarantee, in the
> information-theoretic sense, that a trusted party does not misuse
> information to which it has access?

Its a sort of metapoint.  How can an IETF specification guarantee
things like the above.  It seems much more like a legal issue,
not a protocol issue.

thanks,
John

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

Delivery-date: Tue, 17 Feb 2004 20:11:32 +0000
Content-Class: urn:content-classes:message
Subject: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 12:10:18 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi john,=20
Avi has answered your questions, however please couple of additional =
points/comments inline.
BR,
Farid

>=20
> > One reason for location information is as identified in this draft
> >=20
> =
http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-info=
rmation-00.txt

> Having been through a similar exercize before, I don't much like the =
naming conventions
> in the above draft - section 2.2 for example.=20

[FA] Can you be more specific.  We would be more than happy to use your =
suggestions and advice in improving the naming convention and other =
things in the draft.

> Also, there are some editing nits, for example the '=C6' character in =
section 8. =20

[FA] Good catch -- I thought I fixed that!

> I'd prefer re-use of the work done in GEOPRIV.

[FA] Yes. We need to work with Mark Jones and others to make sure that =
we don't reinvent the wheels.

> Would you be looking at only access, or service specific issues as =
well?
> How does it map to the GEOPRIV deliverables - for example the SIP & =
HTTP
> drafts?=20

[FA] right now, GSMA requirements are for location-based access and =
accounting.  We are also looking at location-based services, however we =
need to figure out how it maps to the GEOPPRIV deliverables as you =
pointed out.

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

Delivery-date: Tue, 17 Feb 2004 19:14:41 +0000
From: Mark Jones <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 14:14:21 -0500

> I wonder if it is ever possible to guarantee, in the 
> information-theoretic sense, that a trusted party does not 
> misuse information to which it has access?
> 

It's a good point, David. I see a parallel here with the privacy policies we
read on web sites before surrendering our email, etc. There is no guarantee
that my personal information will be misused. However, if the service
provider does break the rules governing its use then presumably I have some
legal recourse. 

Similarly, as a subscriber I would like to be able to specify a policy
governing the use of my location information and this policy must be
accessible and evaluated by anyone who determines my location. Depending on
consumer sensitivity to this issue, we may even see network access locations
(hotspots, etc) boasting 'GEOPRIV compliance' as a differentiator.

Now I'm not suggesting RADIUS will be the only protocol involved in
addressing this problem but it is proposed as a transport protocol for the
location information so we should examine the security and privacy
implications now rather than try to bolt something on later.

Regards
Mark

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

Delivery-date: Tue, 17 Feb 2004 18:47:45 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 13:47:30 -0500

John,
I agree with Dave here.
As a minimum you have to trust the various intermediaries.

Even if we send a policy down the pipe saying what may or may not be done
with the infromation.  Ultimately you have to trust the various parties.

In sending the information back to the home network you could encrypte it
using radius encryption mechanism. But each party would still have to be
trusted.  So this is good against the Man-in-the-middle attack.

You could also put the information in a secure tunnel (EAP-message) for end
to end security.

However, I will assert that the weakest link WRT to trust is the node
furthest away from the home network.  For example, in WLAN that access point
would be in Joe-Hacker's dinner.  So even using an EAP scheme would offer
questionable protection.  Unless of course the location information is
coming from the users device (but we are not talking about that in our
draft).

Finally, we need to consider what we are truelly advertizing.  Its not the
user's location but the location of the NAS.  As well, the identity of the
user could be protected using EAP methods. So that while you may have access
to the location information you don't really know who the user is.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: February 17, 2004 1:25 PM
> Cc: [email-masked]; [email-masked]
> Subject: RE: RE: RE: draft-jones-radius-geopriv
> 
> 
> 
> John Loughney writes...
> > > This type of location information needs to be transported to the
> home
> > > network and must only be used for that intention.
> > 
> > How does one guarentee that?
> 
> I wonder if it is ever possible to guarantee, in the 
> information-theoretic sense, that a trusted party does not 
> misuse information to which it has access?
> 
> -- Dave
> 
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 17 Feb 2004 18:25:27 +0000
content-class: urn:content-classes:message
Subject: RE: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 13:25:23 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

John Loughney writes...
> > This type of location information needs to be transported to the
home
> > network and must only be used for that intention.
>=20
> How does one guarentee that?

I wonder if it is ever possible to guarantee, in the
information-theoretic sense, that a trusted party does not misuse
information to which it has access?

-- Dave

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

Delivery-date: Tue, 17 Feb 2004 18:17:23 +0000
content-class: urn:content-classes:message
Subject: RE:  RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 20:16:38 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Avi,

> One reason for location information is as identified in this draft
> =
http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-info=
rmation-00.txt

Having been through a similar exercize before, I don't much like the =
naming conventions
in the above draft - section 2.2 for example.  Also, there are some =
editing nits, for
example the '=C6' character in section 8.  I'd prefer re-use of the work =
done in GEOPRIV.
>=20
> Location information can be used during Authorization to determine =
whether
> the subscriber is allowed access at a given location etc...

Would you be looking at only access, or service specific issues as well?
How does it map to the GEOPRIV deliverables - for example the SIP & HTTP
drafts?=20

> Location information is also needed during billing.  For example the =
tax
> rate may be based on the location where the user has accessed the =
network as
> opposed to the location of the home network.

OK.

> This type of location information needs to be transported to the home
> network and must only be used for that intention.

How does one guarentee that?

John

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

Delivery-date: Tue, 17 Feb 2004 18:12:50 +0000
Date: Tue, 17 Feb 2004 19:12:26 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: Lothar Reith <[email-masked]>
CC: "'Avi Lior'" <[email-masked]>, [email-masked]
Subject: Re: "service-key" in  Lior-Draft ( Radius-Prepaid-Extension)

--------------47CF8DBB6AD9D8297828DF1C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lothar,

> Can someone please shed some light on why the concept of "service key"
> is being introduced.

I think the name "service key" is a bit confusing when we compare with
the Service-Type defined in base RFC.

Service-Key identifies more *granular detail of service* that is offered
to the user. Suppose,  a prepaid PPP user can access to TV-on-demand,
VoIP and vanilla internet access services.

- Service Type attribute carries "framed" value.
- Service Key can specify any or all of "TV-on-demand", "VoIP",
"Internet access" values.

> Is this service subscription information not something which
> architecturally belongs into the the AAA Server and not into the
> Prepaid-Server ?

If the services are prepaid specific, then they should architecturally
belong to Prepaid-server. For instance, prepaid user "X" has access to
service "vanilla internet access" only and prepaid user "Y" has access
to "TV-on-demand" and others. Then, these service keys have to be stored
and communicated by the prepaid server.

regards
Nagi.

--------------47CF8DBB6AD9D8297828DF1C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lothar,
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1>Can someone please shed some light
on why the concept of "service key" is being introduced.</font></blockquote>

<p><br>I think the name "service key" is a bit confusing when we compare
with the Service-Type defined in base RFC.
<p>Service-Key identifies more *granular detail of service* that is offered
to the user. Suppose,&nbsp; a prepaid PPP&nbsp;user can access to TV-on-demand,
VoIP and vanilla internet access services.
<p>- Service Type attribute carries "framed" value.
<br>- Service Key can specify any or all of "TV-on-demand", "VoIP", "Internet
access" values.
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1>Is this service subscription information
not something which architecturally belongs into the the AAA Server and
not into the Prepaid-Server ?</font></blockquote>

<p><br>If the services are prepaid specific, then they should architecturally
belong to Prepaid-server. For instance, prepaid user "X" has access to
service "vanilla internet access" only and prepaid user "Y" has access
to "TV-on-demand" and others. Then, these service keys have to be stored
and communicated by the prepaid server.
<p>regards
<br>Nagi.
<br>&nbsp;</html>

--------------47CF8DBB6AD9D8297828DF1C--

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

Delivery-date: Tue, 17 Feb 2004 18:04:12 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Mark Jones <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 13:03:52 -0500

John,
Perhaps I can jump in here. 

One reason for location information is as identified in this draft
http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa
tion-00.txt

Location information can be used during Authorization to determine whether
the subscriber is allowed access at a given location etc...

Location information is also needed during billing.  For example the tax
rate may be based on the location where the user has accessed the network as
opposed to the location of the home network.

This type of location information needs to be transported to the home
network and must only be used for that intention.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: February 17, 2004 12:40 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: RE: draft-jones-radius-geopriv
> 
> 
> Hi Mark,
> 
> > 1) Provide guidelines for RADIUS implementers needing to transport 
> > subscriber location information and remain compliant with 
> the GEOPRIV 
> > privacy and security requirements. We also wanted to examine the 
> > various roaming scenarios and provide recommendations on 
> how location 
> > information should be sent between AAA servers using RADIUS.
> 
> Question on the second part.  What are the use cases for 
> transporting location info?  I've never really considered 
> RADIUS a transport protocol, so this seems like an odd usage 
> of RADIUS.
> 
> thanks,
> John
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 17 Feb 2004 17:53:54 +0000
content-class: urn:content-classes:message
Subject: RE:  RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 19:39:30 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Mark,

> 1) Provide guidelines for RADIUS implementers needing to transport
> subscriber location information and remain compliant with the GEOPRIV
> privacy and security requirements. We also wanted to examine the =
various
> roaming scenarios and provide recommendations on how location =
information
> should be sent between AAA servers using RADIUS.

Question on the second part.  What are the use cases for transporting
location info?  I've never really considered RADIUS a transport =
protocol,
so this seems like an odd usage of RADIUS.

thanks,
John

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

Delivery-date: Tue, 17 Feb 2004 17:33:28 +0000
Content-Class: urn:content-classes:message
Subject: RE: "service-key" in  Lior-Draft ( Radius-Prepaid-Extension)
Date: Tue, 17 Feb 2004 18:33:00 +0100
From: "Mark Grayson (mgrayson)" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3F57C.17049AAC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Lothar
=20
as I understand it, service key is analagous to the service-identifier
in Diameter Credit Control and is being specified by other
standardzation bodies, e.g., 3GPP
(http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip)
which then assists in rating the pre-paid request.
=20
Cheers,
Mark
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Lothar Reith
Sent: 17 February 2004 16:07
To: 'Avi Lior'; [email-masked]
Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension)

Ladies and Gentlemen,=20

I would like to comment on the RADIUS-Prepaid-Extension Draft.=20

It contains the statement:=20

"The exact definition of these services is not the focus of this draft.
This=20
   definition MAY include a "service key" which can be used to=20
   correlate prepaid requests for access to a service with the service=20
   definition in the prepaid system."=20

Can someone please shed some light on why the concept of "service key"
is being introduced.=20

If I understand correctly, the whole draft is about some prepaid-server
(sometimes also referred to as Quota-Server - or what is the difference
between a Quota-Server and a Prepaid Server?) that MAY be part of a
RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server,
then perhaps no issue, the Service-Key is just another Attribute but I
do not understand what it is good for in this case.

In the more interesting case, where the Quota-Server (or Prepaid Server)
is not part of the AAA Server, the question arises to me, if the
Service-Key is not a trojan-horse that actually deprives the AAA Server
from its original task of service authorization. If I understand the
draft correctly, then the service-key identifies a bundle of a number of
primitive services to which the user has subscribed, hence it belongs
into the AAA-Server and not into the Quota Server. And by the way, watch
out for the definiton of the term "service" - it is not identical to the
definition of "service" in the base RADIUS RFC.

Is this service subscription information not something which
architecturally belongs into the the AAA Server and not into the
Prepaid-Server ?=20

If we start splitting user subscription data over 2 databases (RADIUS
Server and Prepaid Server) things become very messy. Is it design intend
of that draft that the RADIUS Server becomes "transparent" and the
Prepaid-Server takes over ?

Put perhaps somebody can enlight me about the wisdom of introducing the
"service key" concept into this draft (which does not seem to be
included in the related 3GPP2 work on PrePaid Data Service).

I had thought, that the task of a Quota-Server is to manage Quotas, and
not authorize services.=20

my 2 Milli-Euro...=20

Lothar=20

------_=_NextPart_001_01C3F57C.17049AAC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004>Lothar</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D439362217-17022004>as I=20
understand it, service key is analagous to the service-identifier in =
Diameter=20
Credit Control and is being specified by other standardzation bodies, =
e.g., 3GPP=20
(<A=20
href=3D"http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.=
zip">http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip=
</A>)=20
which then assists in rating the pre-paid request.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004>Cheers,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004>Mark</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D439362217-17022004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Lothar Reith<BR><B>Sent:</B> 17 February 2004=20
  16:07<BR><B>To:</B> 'Avi Lior'; =
[email-masked]<BR><B>Subject:</B>=20
  "service-key" in Lior-Draft ( =
Radius-Prepaid-Extension)<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Ladies and Gentlemen,</FONT> </P>
  <P><FONT size=3D2>I would like to comment on the =
RADIUS-Prepaid-Extension=20
  Draft.</FONT> </P>
  <P><FONT size=3D2>It contains the statement:</FONT> </P>
  <P><FONT size=3D2>"The exact definition of these services is not the =
focus of=20
  this draft.&nbsp; This </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
definition MAY=20
  include a "service key" which can be used to </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp; correlate prepaid requests for access to a =
service with=20
  the service </FONT><BR><FONT size=3D2>&nbsp;&nbsp; definition in the =
prepaid=20
  system."</FONT> </P>
  <P><FONT size=3D2>Can someone please shed some light on why the =
concept of=20
  "service key" is being introduced. </FONT></P>
  <P><FONT size=3D2>If I understand correctly, the whole draft is about =
some=20
  prepaid-server (sometimes also referred to as Quota-Server - or what =
is the=20
  difference between a Quota-Server and a Prepaid Server?) that MAY be =
part of a=20
  RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, =
then=20
  perhaps no issue, the Service-Key is just another Attribute but I do =
not=20
  understand what it is good for in this case.</FONT></P>
  <P><FONT size=3D2>In the more interesting case, where the Quota-Server =
(or=20
  Prepaid Server) is not part of the AAA Server, the question arises to =
me, if=20
  the Service-Key is not a trojan-horse that actually deprives the AAA =
Server=20
  from its original task of service authorization. If I understand the =
draft=20
  correctly, then the service-key identifies a bundle of a number of =
primitive=20
  services to which the user has subscribed, hence it belongs into the=20
  AAA-Server and not into the Quota Server. And by the way, watch out =
for the=20
  definiton of the term "service" - it is not identical to the =
definition of=20
  "service" in the base RADIUS RFC.</FONT></P>
  <P><FONT size=3D2>Is this service subscription information not =
something which=20
  architecturally belongs into the the AAA Server and not into the=20
  Prepaid-Server ? </FONT></P>
  <P><FONT size=3D2>If we start splitting user subscription data over 2 =
databases=20
  (RADIUS Server and Prepaid Server) things become very messy. Is it =
design=20
  intend of that draft that the RADIUS Server becomes "transparent" and =
the=20
  Prepaid-Server takes over ?</FONT></P>
  <P><FONT size=3D2>Put perhaps somebody can enlight me about the wisdom =
of=20
  introducing the "service key" concept into this draft (which does not =
seem to=20
  be included in the related 3GPP2 work on PrePaid Data =
Service).</FONT></P>
  <P><FONT size=3D2>I had thought, that the task of a Quota-Server is to =
manage=20
  Quotas, and not authorize services.</FONT> </P>
  <P><FONT size=3D2>my 2 Milli-Euro...</FONT> </P>
  <P><FONT size=3D2>Lothar</FONT> </P><BR><BR>
  <P><FONT size=3D2></FONT> </P><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3F57C.17049AAC--

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

Delivery-date: Tue, 17 Feb 2004 17:08:56 +0000
From: Mark Jones <[email-masked]>
To: 'John Schnizlein' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 12:08:39 -0500

> draft-jones-radius-geopriv specifies a way for a NAS to tell a 
> RADIUS server the location of the NAS. The location of the 
> NAS could be manually configured either in the NAS or in the 
> RADIUS server with which it shares a secret. The 
> radius-geopriv attribute might be added to the RADIUS 
> attributes that are forwarded to a different
> (home) RADIUS server (in the global roaming situation).
> (If this summary is incorrect, please clarify.)
> 

John, 

We set out to write this draft with two main goals:

1) Provide guidelines for RADIUS implementers needing to transport
subscriber location information and remain compliant with the GEOPRIV
privacy and security requirements. We also wanted to examine the various
roaming scenarios and provide recommendations on how location information
should be sent between AAA servers using RADIUS.

2) Provide an access-independent representation of subscriber, device and
network location information and specify how it is encoded in RADIUS. Rather
than invent a new encoding, we would investigate the applicable areas of the
GMLv3 efforts.

Regards
Mark

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

Delivery-date: Tue, 17 Feb 2004 16:58:38 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 17:58:06 +0100

dhcp: distributes its own location information and has control over it. 
aaa: network distributes location information about the user for
authorization, charging,.... (and maybe for other applications once the
infrastructure is setup). 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 5:56 PM
> To: Tschofenig Hannes
> Cc: [email-masked]
> Subject: RE: draft-jones-radius-geopriv
> 
> 
> > regarding your dhcp example: the dhcp scenario is a little bit
> >different to the radius/diameter example since the location 
> information
> >which is distributed is not only about the visited network but rather
> >about the user (and also used in this sense).
> 
> I'm not sure there really is a difference this way.
> 

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

Delivery-date: Tue, 17 Feb 2004 16:43:51 +0000
Date: Tue, 17 Feb 2004 08:55:34 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
cc: [email-masked]
Subject: RE: draft-jones-radius-geopriv

> regarding your dhcp example: the dhcp scenario is a little bit
>different to the radius/diameter example since the location information
>which is distributed is not only about the visited network but rather
>about the user (and also used in this sense).

I'm not sure there really is a difference this way.

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

Delivery-date: Tue, 17 Feb 2004 16:36:37 +0000
Date: Tue, 17 Feb 2004 08:47:03 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-jones-radius-geopriv

> Why not re-use the encoding used in the civil version for DHCP?
> Compression will not help significantly unless you use a SIGCOMP
> approach and your dictionary is exactly right. The complexity of doing
> that boggles the mind.

Yes, that is the simplest thing that comes to mind.

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

Delivery-date: Tue, 17 Feb 2004 16:07:36 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, [email-masked]
Subject: "service-key" in  Lior-Draft ( Radius-Prepaid-Extension)
Date: Tue, 17 Feb 2004 16:07:09 -0000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3F570.18BC411E
Content-Type: text/plain

Ladies and Gentlemen,

I would like to comment on the RADIUS-Prepaid-Extension Draft.

It contains the statement:

"The exact definition of these services is not the focus of this draft.
This 
   definition MAY include a "service key" which can be used to 
   correlate prepaid requests for access to a service with the service 
   definition in the prepaid system."

Can someone please shed some light on why the concept of "service key" is
being introduced. 

If I understand correctly, the whole draft is about some prepaid-server
(sometimes also referred to as Quota-Server - or what is the difference
between a Quota-Server and a Prepaid Server?) that MAY be part of a RADIUS
Server. Okay, if the prepaid server IS part of a RADIUS server, then perhaps
no issue, the Service-Key is just another Attribute but I do not understand
what it is good for in this case.

In the more interesting case, where the Quota-Server (or Prepaid Server) is
not part of the AAA Server, the question arises to me, if the Service-Key is
not a trojan-horse that actually deprives the AAA Server from its original
task of service authorization. If I understand the draft correctly, then the
service-key identifies a bundle of a number of primitive services to which
the user has subscribed, hence it belongs into the AAA-Server and not into
the Quota Server. And by the way, watch out for the definiton of the term
"service" - it is not identical to the definition of "service" in the base
RADIUS RFC.

Is this service subscription information not something which architecturally
belongs into the the AAA Server and not into the Prepaid-Server ? 

If we start splitting user subscription data over 2 databases (RADIUS Server
and Prepaid Server) things become very messy. Is it design intend of that
draft that the RADIUS Server becomes "transparent" and the Prepaid-Server
takes over ?

Put perhaps somebody can enlight me about the wisdom of introducing the
"service key" concept into this draft (which does not seem to be included in
the related 3GPP2 work on PrePaid Data Service).

I had thought, that the task of a Quota-Server is to manage Quotas, and not
authorize services.

my 2 Milli-Euro...

Lothar

 

------_=_NextPart_001_01C3F570.18BC411E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>&quot;service-key&quot; in  Lior-Draft ( =
Radius-Prepaid-Extension)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ladies and Gentlemen,</FONT>
</P>

<P><FONT SIZE=3D2>I would like to comment on the =
RADIUS-Prepaid-Extension Draft.</FONT>
</P>

<P><FONT SIZE=3D2>It contains the statement:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;The exact definition of these services is not =
the focus of this draft.&nbsp; This </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; definition MAY include a "service key" =
which can be used to </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; correlate prepaid requests for access =
to a service with the service </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; definition in the prepaid =
system.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Can someone please shed some light on why the concept =
of &quot;service key&quot; is being introduced. </FONT>
</P>

<P><FONT SIZE=3D2>If I understand correctly, the whole draft is about =
some prepaid-server (sometimes also referred to as Quota-Server - or =
what is the difference between a Quota-Server and a Prepaid Server?) =
that MAY be part of a RADIUS Server. Okay, if the prepaid server IS =
part of a RADIUS server, then perhaps no issue, the Service-Key is just =
another Attribute but I do not understand what it is good for in this =
case.</FONT></P>

<P><FONT SIZE=3D2>In the more interesting case, where the Quota-Server =
(or Prepaid Server) is not part of the AAA Server, the question arises =
to me, if the Service-Key is not a trojan-horse that actually deprives =
the AAA Server from its original task of service authorization. If I =
understand the draft correctly, then the service-key identifies a =
bundle of a number of primitive services to which the user has =
subscribed, hence it belongs into the AAA-Server and not into the Quota =
Server. And by the way, watch out for the definiton of the term =
&quot;service&quot; - it is not identical to the definition of =
&quot;service&quot; in the base RADIUS RFC.</FONT></P>

<P><FONT SIZE=3D2>Is this service subscription information not =
something which architecturally belongs into the the AAA Server and not =
into the Prepaid-Server ? </FONT></P>

<P><FONT SIZE=3D2>If we start splitting user subscription data over 2 =
databases (RADIUS Server and Prepaid Server) things become very messy. =
Is it design intend of that draft that the RADIUS Server becomes =
&quot;transparent&quot; and the Prepaid-Server takes over ?</FONT></P>

<P><FONT SIZE=3D2>Put perhaps somebody can enlight me about the wisdom =
of introducing the &quot;service key&quot; concept into this draft =
(which does not seem to be included in the related 3GPP2 work on =
PrePaid Data Service).</FONT></P>

<P><FONT SIZE=3D2>I had thought, that the task of a Quota-Server is to =
manage Quotas, and not authorize services.</FONT>
</P>

<P><FONT SIZE=3D2>my 2 Milli-Euro...</FONT>
</P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C3F570.18BC411E--

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

Delivery-date: Tue, 17 Feb 2004 15:46:03 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 16:45:32 +0100

hi henning, 

thanks for you quick response.

> schofenig Hannes wrote:
> 
>  > hi henning,
>  > do you remember our discussions in the washington interim meeting? 
> there we
>  > considered the http proposals for distributing location 
> information. 
> andrew
>  > daviels proposed a custom location information format. there we 
> argued that
>  > we have to consider privacy issues (and therefore our 
> results of the 
> geopriv
>  > working group). the geopriv working group decided to build 
> their location
>  > objects based on xml (and also the policies). some size 
> considerations go
>  > along with it (also with the usage of s/mime).
> 
> 
> That's putting it rather mildly... Given the trivial 
> structure for the 
> basic PIDF privacy information, I'm not convinced that we always need 
> the full generality of a GML object. I'd like to hear a technical, 
> rather than procedural, argument for disallowing that. (In HTTP, the 
> size argument was largely a non-issue.)

i have not objections against adding privacy issues to other drafts. 

as you know i was not a big fan of gml at the beginning (which motivated
jorge and christian to come up with their own location object draft) but
looking deeper in it it turns out to contain useful stuff. looking at the
features provided by it would not hurt. 

> 
> There might be more general value in a restricted format, as 
> it could be 
> applicable to other limited-functionality and 
> bandwidth/size-constrained 
> cases. There is clearly precedent for coding information in multiple 
> formats; the DHCP drafts are examples of that.
> 
> The other alternative is http://www.w3.org/TR/wbxml/, but that 'note' 
> comes with warning labels that indicate that this is not exactly a 
> future-proof effort.

true. i also saw this link.
another alternative is to switch to diameter. 

> 
>  >
>  > regarding your dhcp example: the dhcp scenario is a little bit 
> different to the radius/diameter example
>  > since the location information which is distributed is not 
> only about the
>  > visited network but rather about the user (and also used 
> in this sense).
> 
> 
> It would be a trivial exercise to embed the privacy flags into a TLV 
> encoding.
i agree with you. it wouldn't be a drawback to merge some other aspects as
well. 

> 
> I have nothing against XML, but I'm worried about declaring it a 
> religion
.. which i wouldn't do. 

> where any questioning of its universal applicability is 
> considered sacrilege.

our draft and our intention does not go that far. it raises some issues
(privacy, what location information could be useful,security,...), shows
scenarios and points to work done in other places in the ietf. i think is
fair todo that. 

ciao
hannes

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

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

Delivery-date: Tue, 17 Feb 2004 15:44:43 +0000
Content-Class: urn:content-classes:message
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 07:43:43 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "John Schnizlein" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>, <[email-masked]>

> A summary of the various intersections might be useful here:
> (for others - I know Bernard knows this background)
>=20
> draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a=20
> DHCP server to give a host the host's location, using (circuit-ID)
> information from the relay-agent and knowledge of the wiring plant.
>=20
> draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP
> relay agent to relay RADIUS information to the DHCP server for its
> use in allocating configuration options.
>=20
> draft-jones-radius-geopriv specifies a way for a NAS to tell a=20
> RADIUS server the location of the NAS. The location of the NAS could
> be manually configured either in the NAS or in the RADIUS server
> with which it shares a secret. The radius-geopriv attribute might
> be added to the RADIUS attributes that are forwarded to a different
> (home) RADIUS server (in the global roaming situation).
> (If this summary is incorrect, please clarify.)
>=20
> Before combining these ideas in a creative way, one would need to
> have a clear understanding of whose location information is needed
> where, and which provider of the information has the best=20
> access to it.
> Since this analysis is already too difficult for some of us to want
> to attempt, making it worse with different information formats seems
> like over-kill.
>=20
> John
>=20
>=20

Thanks for the summary Johh.  There is also another related draft
(draft-adrangi-radius-location-information-attribute-00.txt) that
specifies a way for an Access Network (NAS) to convey the Access Network
operational ownership and location information to the home RADIUS
server.  This draft is based on the requirements defined by GSMA
operators and Wifi PA3 (public access) to enable location-based
authentication, location-based services, and location-based billing and
accounting use-scenarios. =20

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 17 Feb 2004 15:25:35 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Bof at next IETF? 
Date: Tue, 17 Feb 2004 10:28:03 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Those drafts that call for extensions to RADIUS that are outside the
> RADEXT proposed charter, and would break backwards compatibility with
> the existing RADIUS RFCs and RADIUS implementations, should never, IMHO,
> be published as Standards Track RFCs, and I have some serious doubts as
> to whether they should be published as Informational RFCs.

  The client kickstart at least has zero impact on existing
implementations.  If your server doesn't support dynamic registration
of clients, then the current methods (or lack thereof) are OK.  If
your server does support it, then if the clients support it, you get
an incremental piece of security in your network.

  Alan DeKok.

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

Delivery-date: Tue, 17 Feb 2004 15:24:25 +0000
Date: Tue, 17 Feb 2004 10:24:15 -0500
From: Henning Schulzrinne <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: draft-jones-radius-geopriv

schofenig Hannes wrote:

 > hi henning,
 > do you remember our discussions in the washington interim meeting? 
there we
 > considered the http proposals for distributing location information. 
andrew
 > daviels proposed a custom location information format. there we 
argued that
 > we have to consider privacy issues (and therefore our results of the 
geopriv
 > working group). the geopriv working group decided to build their location
 > objects based on xml (and also the policies). some size considerations go
 > along with it (also with the usage of s/mime).

That's putting it rather mildly... Given the trivial structure for the 
basic PIDF privacy information, I'm not convinced that we always need 
the full generality of a GML object. I'd like to hear a technical, 
rather than procedural, argument for disallowing that. (In HTTP, the 
size argument was largely a non-issue.)

There might be more general value in a restricted format, as it could be 
applicable to other limited-functionality and bandwidth/size-constrained 
cases. There is clearly precedent for coding information in multiple 
formats; the DHCP drafts are examples of that.

The other alternative is http://www.w3.org/TR/wbxml/, but that 'note' 
comes with warning labels that indicate that this is not exactly a 
future-proof effort.

 >
 > regarding your dhcp example: the dhcp scenario is a little bit 
different to the radius/diameter example
 > since the location information which is distributed is not only about the
 > visited network but rather about the user (and also used in this sense).

It would be a trivial exercise to embed the privacy flags into a TLV 
encoding.

I have nothing against XML, but I'm worried about declaring it a 
religion where any questioning of its universal applicability is 
considered sacrilege.

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

Delivery-date: Tue, 17 Feb 2004 15:08:02 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>
Cc: "'John Schnizlein'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 16:07:36 +0100

hi henning, 

do you remember our discussions in the washington interim meeting? there we
considered the http proposals for distributing location information. andrew
daviels proposed a custom location information format. there we argued that
we have to consider privacy issues (and therefore our results of the geopriv
working group). the geopriv working group decided to build their location
objects based on xml (and also the policies). some size considerations go
along with it (also with the usage of s/mime). 

regarding your dhcp example: 
the dhcp scenario is a little bit different to the radius/diameter example
since the location information which is distributed is not only about the
visited network but rather about the user (and also used in this sense).

ciao
hannes

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 3:44 PM
> To: Tschofenig Hannes
> Cc: 'John Schnizlein'; [email-masked]; [email-masked]
> Subject: Re: draft-jones-radius-geopriv
> 
> 
> Why not re-use the encoding used in the civil version for DHCP? 
> Compression will not help significantly unless you use a SIGCOMP 
> approach and your dictionary is exactly right. The complexity 
> of doing 
> that boggles the mind.
> 
> Tschofenig Hannes wrote:
> 
> > hi john, 
> > 
> > thanks for your observation. 
> > 
> > i see the following ways to tackle this problem: 
> > - forget xml and use a different encoding which is more "lighweight"
> > - switch to diameter 
> > - compress xml objects
> > 
> > i personally think that the privacy issues are worth 
> thinking about these
> > options. 
> > 
> > ciao
> > hannes
> > 
> > 
> >>-----Original Message-----
> >>From: John Schnizlein [mailto:[email-masked]]
> >>Sent: Monday, February 16, 2004 1:53 AM
> >>To: Tschofenig Hannes
> >>Cc: [email-masked]; [email-masked]
> >>Subject: Re: draft-jones-radius-geopriv
> >>
> >>
> >>I am sorry I quoted the wrong part of RFC 2865.
> >>The length of an attribute is at most 255, one octet [page 25].
> >>It seems unlikely that GML, or any XML, would be efficient 
> >>enough to be carried in a RADIUS attribute.
> >>
> >>At 01:12 PM 2/10/2004, John Schnizlein wrote:
> >>
> >>>>One concern, if this location configuration information (LCI)
> >>>>is to be carried over RADIUS, is that the example in section 6
> >>>>seems to be 993 characters long. This one attribute seems to be
> >>>>taking a large share of the maximum RADIUS packet size of 4096.
> >>>>[RFC 2865, p 15] Is there enough room for everything else that
> >>>>would be expected with this attribute?
> >>
> > 
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 17 Feb 2004 14:44:57 +0000
Date: Tue, 17 Feb 2004 09:44:14 -0500
From: Henning Schulzrinne <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
CC: "'John Schnizlein'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-jones-radius-geopriv

Why not re-use the encoding used in the civil version for DHCP? 
Compression will not help significantly unless you use a SIGCOMP 
approach and your dictionary is exactly right. The complexity of doing 
that boggles the mind.

Tschofenig Hannes wrote:

> hi john, 
> 
> thanks for your observation. 
> 
> i see the following ways to tackle this problem: 
> - forget xml and use a different encoding which is more "lighweight"
> - switch to diameter 
> - compress xml objects
> 
> i personally think that the privacy issues are worth thinking about these
> options. 
> 
> ciao
> hannes
> 
> 
>>-----Original Message-----
>>From: John Schnizlein [mailto:[email-masked]]
>>Sent: Monday, February 16, 2004 1:53 AM
>>To: Tschofenig Hannes
>>Cc: [email-masked]; [email-masked]
>>Subject: Re: draft-jones-radius-geopriv
>>
>>
>>I am sorry I quoted the wrong part of RFC 2865.
>>The length of an attribute is at most 255, one octet [page 25].
>>It seems unlikely that GML, or any XML, would be efficient 
>>enough to be carried in a RADIUS attribute.
>>
>>At 01:12 PM 2/10/2004, John Schnizlein wrote:
>>
>>>>One concern, if this location configuration information (LCI)
>>>>is to be carried over RADIUS, is that the example in section 6
>>>>seems to be 993 characters long. This one attribute seems to be
>>>>taking a large share of the maximum RADIUS packet size of 4096.
>>>>[RFC 2865, p 15] Is there enough room for everything else that
>>>>would be expected with this attribute?
>>
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 17 Feb 2004 12:40:12 +0000
Date: Tue, 17 Feb 2004 15:39:23 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: subtypes

My two cents (again :-) )about possible attribute format to carry 
subattributes.
When I say "subattribute" I speak about service or application specific
attributes which must be sended to specific hardware or software.

Type -- Attribute type.  may be 226 for example

SoA ID -- Service or Application ID.  We can assign standard numbers to
services (SIP, WiFi, LAN etc) and applications (Prepaid etc). So all
vendors can use it in their products.

SoA Type -- Service or Application Type. This is SoA attribute type.

Tag -- tag to allow attribute assemble/disassemle (like EAP)

+---------------------------------------------------------------+
|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 (226)  |    Length     |             SoA ID            |
+---------------+---------------+-------------------------------+
|             SoA Type          |      Tag      |  SoA length   |
+---------------+---------------+---------------+---------------+
|    Value...
+---------------+---

I hope it maybe really help to solve our "subtype problem".

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

Delivery-date: Tue, 17 Feb 2004 09:38:03 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'John Schnizlein'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Tue, 17 Feb 2004 10:37:39 +0100

hi john, 

thanks for your observation. 

i see the following ways to tackle this problem: 
- forget xml and use a different encoding which is more "lighweight"
- switch to diameter 
- compress xml objects

i personally think that the privacy issues are worth thinking about these
options. 

ciao
hannes

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Monday, February 16, 2004 1:53 AM
> To: Tschofenig Hannes
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-jones-radius-geopriv
> 
> 
> I am sorry I quoted the wrong part of RFC 2865.
> The length of an attribute is at most 255, one octet [page 25].
> It seems unlikely that GML, or any XML, would be efficient 
> enough to be carried in a RADIUS attribute.
> 
> At 01:12 PM 2/10/2004, John Schnizlein wrote:
> >> One concern, if this location configuration information (LCI)
> >> is to be carried over RADIUS, is that the example in section 6
> >> seems to be 993 characters long. This one attribute seems to be
> >> taking a large share of the maximum RADIUS packet size of 4096.
> >> [RFC 2865, p 15] Is there enough room for everything else that
> >> would be expected with this attribute?
> 

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

Delivery-date: Tue, 17 Feb 2004 09:25:10 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: Formatting problem with draft-sterman-aaa-sip-01.txt
Date: Tue, 17 Feb 2004 10:25:00 +0100

John Loughney wrote:

> Is it just me, or does:
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
> seem to have 2 versions of the text appended to each other?

Urgh, you are right. I've just checked my Sent-Box, the error must
have occurred at [email-masked]. The mail I've sent to them
contained the xml2rfc source and the txt version generated from it.
To be on the safe side, I included the txt version as text and as
attachment. Maybe some script cat'ed them together.

Wolfgang

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

Delivery-date: Tue, 17 Feb 2004 08:43:26 +0000
content-class: urn:content-classes:message
Subject: Formatting problem with draft-sterman-aaa-sip-01.txt
Date: Tue, 17 Feb 2004 10:43:10 +0200
From: <[email-masked]>
To: <[email-masked]>

Hi all,

Is it just me, or does:

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt

seem to have 2 versions of the text appended to each other?

John

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

Delivery-date: Tue, 17 Feb 2004 07:13:16 +0000
Date: Mon, 16 Feb 2004 23:12:50 -0800
To: <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Bof at next IETF?
Cc: <[email-masked]>

Hello, Greg, John,

Comments inline ...

At 02:10 PM 2/16/2004 +0200, [email-masked] wrote:
>Hi Greg,
>
> > This does seem like a good thing to discuss.  Seems to me that
> > it would be beneficial to have some way of enforcing forward
> > compatibility from RADIUS to Diameter.  A working group with
> > both protocols in its purview might provide that venue for
> > enforcement- or at least awareness.  Also, most of the work
> > item areas are solution oriented, not protocol specific.
> >
> > I believe ITU-T is looking favorably at applying 3GPP's IMS
> > architecture to DSL & Cable.  That leads me to believe that
> > more Diameter applications will be on the way.  If AAA-WG is
> > going to shutdown, we need an area for these new AAA applications
> > to develop.
>
>I agree with you on this point.  A question to the chairs -
>should we send text on the proposed charter with this in mind?

Good point. We should go ahead and propose text for the charter
if there is no objection. We can perhaps use the following list for
items to be included in the charter (thanks to Avi for posting this list):

http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-pwlan
-00.txt
This will be updated by deadline

http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa
tion-00.txt
This is new work.

http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capabilit
y-00.txt
This is new work

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
Updates previous one

http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0
1.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart-
01.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.txt

http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02.
txt
This will be updated.

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping-
00.txt
This will be updated

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi
on-00.txt
This is new work but outside scope of charter.

http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt
This is new work

 >From IETF 58:

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping-
00.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart-
01.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-sspp-snmp-01.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02.
txt

http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounti
ng-00.txt

http://www.watersprings.org/pub/id/draft-sterman-aaa-sip-00.txt

http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

http://www.ietf.org/internet-drafts/draft-aboba-context-802-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roa
ming-01.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extensio
n-for-pwlan-00.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0
1.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-pe-discovery-04.tx
t

Please post any additional drafts if not included in the above list.

Thanks,
Parviz

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

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

Delivery-date: Tue, 17 Feb 2004 04:59:40 +0000
content-class: urn:content-classes:message
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)
Date: Tue, 17 Feb 2004 06:59:15 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Wolfgang,

> > I think that if Extension X provides the exact same functionality as =
VSA y,
> > what is the need to support Extension X?

> If VSA is identical to Extension X, you are right. But what if VSA y =
does not
> care about DIAMETER interopability and Extension X does? When I =
submitted
> draft-sterman-aaa-sip, one of the first question was about DIAMETER
> interopability. There was a problem that could be settled after some
> discussion. In this particular case, we found that a change in the
> DIAMETER SIP application draft was the best solution. With a VSA, this =

> valuable discussion wouldn't have happened.

I do think your update is an improvement, and that is a good thing.  =
Getting
the Diamatere SIP application to be RADIUS friendly is important as =
well. We
are probably moving foward on all of this, somewhat slowly ...

John

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

Delivery-date: Mon, 16 Feb 2004 22:45:17 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>
Cc: [email-masked]
Subject: If not BOF then WG?
Date: Mon, 16 Feb 2004 17:44:49 -0500

Bernard,

Based on this email(below) then are we to conclude that there is still a
move to progress towards a RADIUS working group?

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, February 16, 2004 2:42 PM
> To: Greg Weber
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: RADIUS and complex attributes
> 
> 
> > I think it would be very helpful to produce some more modern 
> > recommendations on how to 
> format/tag/concatenate/encrypt/etc VSAs and 
> > when to pursue IETF space use vs. vendor (SDO) specific. 
> Perhaps this 
> > is worthy of charter work-item inclusion.
> 
> I think it is.  There has been some discussion about one of 
> the following types of documents:
> 
> a. RADIUS Implementation Issues and Fixes
> b. RADIUS attribute design guidelines
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 16 Feb 2004 22:16:49 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Extending a RADIUS attribute (was subtypes....)
Date: Mon, 16 Feb 2004 17:16:30 -0500

David,

So I agree that perhaps the unreliable was not the correct word to use (as
you suggest). But nevertheless it has problems.

If I actually need to have multiple values of the attribute then simply
repeating the attribute  is not workable.  It would be difficult if not
impossible for the RADIUS server to tell whether the next attribute is a
continuation of the previous one or a new one.

Strangely someone asked me just this question about my redirection draft.

There the REDIRECTION rule can get lengthy and I need to be able to send
more than one.  Therefore I replied as follows:
 
I can extend the content of the REDIRECT-RULE attribute over back to back
attributes.  But this method is not good if we want more then one REDIRECT
attribute and we do.
 
Therefore the correct way to do this is to include the length of the overall
data and then split it over back-to-back attributes.  Another method is to
reserve a key word such as "more".  If "more" is found at the end of the
first chunk then the next attribute is an extension of the first.  Both
method s would work in my case because the value type of the attribute is
TEXT.

But this does highlight the fact that there is no standard way to extend
attributes in RADIUS that works across the board.  Hence my discussion many
moons ago about extending attributes.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, February 16, 2004 4:36 PM
> To: Avi Lior; [email-masked]
> Subject: RE: subtypes (was: HTTP digest and RADIUS; new 
> version of the Stermandraft)
> 
> 
> Avi Lior writes...
> 
> > Today if I have a string attribute that is longer than 253 octets
> > -- I could extend it by putting the contents in back-to-back
> > attributes.  This however is not a very reliable way of extending 
> > an attribute.
> 
> My understanding, from the context of early RADIUS WG 
> discussions, is that this is exactly what is intended.  The 
> RFCs are less that crystal clear on this issue, however.  The 
> only RADIUS attributes that have ordering requirements (e.g. 
> in proxy handling) are those string types that can contain a 
> continuation of a string value from one attribute to another. 
>  The requirement to preserve order makes the re-assembly possible.
> 
> As to reliability, I see no reason that this method is any 
> more unreliable than the underlying RADIUS transport 
> mechanism.  It may be slightly cumbersome, but I would not 
> characterize it as unreliable.
> 
> -- Dave
> 
> 
> 
> 

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

Delivery-date: Mon, 16 Feb 2004 21:35:47 +0000
content-class: urn:content-classes:message
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the  Stermandraft)
Date: Mon, 16 Feb 2004 16:35:32 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Today if I have a string attribute that is longer than 253 octets
> -- I could extend it by putting the contents in back-to-back=20
> attributes.  This however is not a very reliable way of extending=20
> an attribute.

My understanding, from the context of early RADIUS WG discussions, is
that this is exactly what is intended.  The RFCs are less that crystal
clear on this issue, however.  The only RADIUS attributes that have
ordering requirements (e.g. in proxy handling) are those string types
that can contain a continuation of a string value from one attribute to
another.  The requirement to preserve order makes the re-assembly
possible.

As to reliability, I see no reason that this method is any more
unreliable than the underlying RADIUS transport mechanism.  It may be
slightly cumbersome, but I would not characterize it as unreliable.

-- Dave

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

Delivery-date: Mon, 16 Feb 2004 21:11:55 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Victor Gamov <[email-masked]>, [email-masked]
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the  St ermandraft)
Date: Mon, 16 Feb 2004 16:11:44 -0500

See inline.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, February 16, 2004 11:17 AM
> To: Victor Gamov; [email-masked]
> Subject: RE: subtypes (was: HTTP digest and RADIUS; new 
> version of the Stermandraft)
> 
> 
> Victor Gamov writes...
> 
> > Yes, but I don't say that we must increase attribute 
> length.  We must 
> > propose method to join attribute values placed in different 
> attributes 
> > with some "tag".  Like EAP for example.
> 
> Application layer fragmentation and reassembly of attributes 
> already exists in RADIUS.  It is used for string attributes, 
> such as Filter-ID or Framed-Route, in addition to EAP-Message.

RADIUS has no way of addressing fragmentation and reassembly of attributes
for "string" attributes.

If you are talking about the fact the Filter-Id and Framed-Route can appear
more then once in a packet , the intent of that is not to function as a
fragmentation and reassembly mechanism.

EAP-Message is entirely different story.  Its really a transport within a
tranpsort and does address this issue within the EAP-Message.

Today if I have a string attribute that is longer than 253 octets -- I could
extend it by putting the contents in back-to-back attributes.  This however
is not a very reliable way of extending an attribute.

Also recall, that we have many discussion on this topic when I put forward
the radius attribute extension drafts.  During that discussion I proposed a
method of doing this (but that is entirely a different story)

Avi

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

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

Delivery-date: Mon, 16 Feb 2004 19:30:55 +0000
Date: Mon, 16 Feb 2004 11:42:26 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Greg Weber <[email-masked]>
cc: "Joel M. Halpern" <[email-masked]>, [email-masked]
Subject: Re: RADIUS and complex attributes

> I think it would be very helpful to produce some more modern
> recommendations on how to format/tag/concatenate/encrypt/etc VSAs
> and when to pursue IETF space use vs. vendor (SDO) specific.
> Perhaps this is worthy of charter work-item inclusion.

I think it is.  There has been some discussion about one of the following
types of documents:

a. RADIUS Implementation Issues and Fixes
b. RADIUS attribute design guidelines

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

Delivery-date: Mon, 16 Feb 2004 17:22:48 +0000
From: Greg Weber <[email-masked]>
Subject: Re: RADIUS and complex attributes
To: [email-masked] (Bernard Aboba)
Date: Mon, 16 Feb 2004 12:22:12 -0500 (EST)
Cc: [email-masked] (Joel M. Halpern), [email-masked]

> 
> > For many environments, there are very good reasons to prefer and move to
> > standards.
> 
> VSAs were never intended for general purpose use, which is what I think
> the problem is here.  But protocols such as SNMP can be used by SDOs to
> create SDO-specific MIBs, and it does seem reasonable to enable SDOs to
> create SDO-specific attributes.  So far, they have not done a good job of
> this partly because they have chosen the VSA format suggested in RFC 2865
> (how silly of them!) which only supports an 8 bit type code field.  But
> perhaps with some help and guidelines from the IETF this situation might
> be improved.

I think it would be very helpful to produce some more modern
recommendations on how to format/tag/concatenate/encrypt/etc VSAs
and when to pursue IETF space use vs. vendor (SDO) specific.
Perhaps this is worthy of charter work-item inclusion.

> > Sticking with VSAs for widely need features is simply a mistake.
> 
> I'd agree for features that are not specific to a particular access
> technology.  However, it's worth noting that Enterprise MIBs are very
> widely implemented today;  many of the IEEE 802 MIBs fit in this category,
> and interoperability has not been harmed by this.  In the long term it is
> not reasonable to force all AAA work to go through the IETF since this
> does not scale.  We need a mechanism akin to "MIB Doctors" for review,
> "Enterprise MIBs" for legitimate extensions by SDOs (e.g. no new commands
> or data types), and "Design guidelines" to provide advice on how to go
> about it.
> 
> 
> > Allow complex attributes.  Call them subtypes if you like
> 
> There is quite a difference between support of "complex attributes" and
> "grouped AVPs" (e.g. sub-types).  The former typically requires a data
> definition language, while the latter does not.  It is also worth noting
> that the Diameter definition of "grouped AVPs" only allows one level of
> grouping, 

That is not my understanding based on Section 4.4 of RFC 3588:
  "It is possible to include an AVP with a Grouped 
   type within a Grouped type, that is, to nest them."

I thought they could be recursive; please correct me if I'm wrong.

Greg

> so more than this cannot be allowed in RADIUS without breaking
> DIAMETER/RADIUS compatibility.
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 16 Feb 2004 16:49:33 +0000
Date: Mon, 16 Feb 2004 19:49:18 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: subtypes

Bernard Aboba wrote:
>>So, we can propose new extension with new attribute where we can join
>>large attribute values or propose new RADIUS behaviour for VSA with
>>VendorId=0
> 
> 
> It's hard to see how VSAs can address the length issue since
> all RADIUS attributes are defined in RFC 2865 to have a Length field of 8
> bits.
> 
> However, this approach could allow for grouping and possibly attribute
> extension since RFC 2865 does allow for grouping of attributes within a
> VSA.
> 
> Some questions:
> 
> a) Would single-level grouping (e.g. no groups within groups) within a
> VSA with vendorid = 0 address the issues?  Or do we need new data types or
> even complex data types (with a datatype definition language)?
> 
> b) Since VSAs are ignorable by the RADIUS client, are all contemplated
> "grouped" attributes optional?  How do we distinguish between mandatory
> and optional attributes?

I think that we must use new attribute with format like VSA (26) and 
with special behavior for attribute asseble/disassemble.

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

Delivery-date: Mon, 16 Feb 2004 16:46:33 +0000
Date: Mon, 16 Feb 2004 19:45:56 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the  Stermandraft)

Nelson, David wrote:
> Victor Gamov writes...
> 
> 
>>Yes, but I don't say that we must increase attribute length.  We must
>>propose method to join attribute values placed in different attributes
>>with some "tag".  Like EAP for example.
> 
> 
> Application layer fragmentation and reassembly of attributes already
> exists in RADIUS.  It is used for string attributes, such as Filter-ID
> or Framed-Route, in addition to EAP-Message.

Yes. But I still think that we must propose:
1) standard service-specific attributes for many services (SIP, WiFi etc)
2) standard way for fragmentation and assembly of this attributes 
(attribute assemble/disassemble, AAD)

If we do it we will have mechanism to carry (possibly) large attributes 
and all vendors will be use service-specific attributes and AAD.

Is it solve our "subtype" problem?

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

Delivery-date: Mon, 16 Feb 2004 16:45:52 +0000
Date: Mon, 16 Feb 2004 08:57:32 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
cc: [email-masked]
Subject: Re: RADIUS and complex attributes

> For many environments, there are very good reasons to prefer and move to
> standards.

VSAs were never intended for general purpose use, which is what I think
the problem is here.  But protocols such as SNMP can be used by SDOs to
create SDO-specific MIBs, and it does seem reasonable to enable SDOs to
create SDO-specific attributes.  So far, they have not done a good job of
this partly because they have chosen the VSA format suggested in RFC 2865
(how silly of them!) which only supports an 8 bit type code field.  But
perhaps with some help and guidelines from the IETF this situation might
be improved.

> Sticking with VSAs for widely need features is simply a mistake.

I'd agree for features that are not specific to a particular access
technology.  However, it's worth noting that Enterprise MIBs are very
widely implemented today;  many of the IEEE 802 MIBs fit in this category,
and interoperability has not been harmed by this.  In the long term it is
not reasonable to force all AAA work to go through the IETF since this
does not scale.  We need a mechanism akin to "MIB Doctors" for review,
"Enterprise MIBs" for legitimate extensions by SDOs (e.g. no new commands
or data types), and "Design guidelines" to provide advice on how to go
about it.

> Allow complex attributes.  Call them subtypes if you like

There is quite a difference between support of "complex attributes" and
"grouped AVPs" (e.g. sub-types).  The former typically requires a data
definition language, while the latter does not.  It is also worth noting
that the Diameter definition of "grouped AVPs" only allows one level of
grouping, so more than this cannot be allowed in RADIUS without breaking
DIAMETER/RADIUS compatibility.

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

Delivery-date: Mon, 16 Feb 2004 16:31:59 +0000
Date: Mon, 16 Feb 2004 08:43:32 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Victor Gamov <[email-masked]>
cc: [email-masked]
Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)

> So, we can propose new extension with new attribute where we can join
> large attribute values or propose new RADIUS behaviour for VSA with
> VendorId=0

It's hard to see how VSAs can address the length issue since
all RADIUS attributes are defined in RFC 2865 to have a Length field of 8
bits.

However, this approach could allow for grouping and possibly attribute
extension since RFC 2865 does allow for grouping of attributes within a
VSA.

Some questions:

a) Would single-level grouping (e.g. no groups within groups) within a
VSA with vendorid = 0 address the issues?  Or do we need new data types or
even complex data types (with a datatype definition language)?

b) Since VSAs are ignorable by the RADIUS client, are all contemplated
"grouped" attributes optional?  How do we distinguish between mandatory
and optional attributes?

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

Delivery-date: Mon, 16 Feb 2004 16:17:32 +0000
content-class: urn:content-classes:message
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the  Stermandraft)
Date: Mon, 16 Feb 2004 11:17:21 -0500
From: "Nelson, David" <[email-masked]>
To: "Victor Gamov" <[email-masked]>, <[email-masked]>

Victor Gamov writes...

> Yes, but I don't say that we must increase attribute length.  We must
> propose method to join attribute values placed in different attributes
> with some "tag".  Like EAP for example.

Application layer fragmentation and reassembly of attributes already
exists in RADIUS.  It is used for string attributes, such as Filter-ID
or Framed-Route, in addition to EAP-Message.

-- Dave

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

Delivery-date: Mon, 16 Feb 2004 15:36:10 +0000
Date: Mon, 16 Feb 2004 18:35:27 +0300
From: Victor Gamov <[email-masked]>
To: Nagi <[email-masked]>, [email-masked]
Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the  Stermandraft)

Nagi wrote:
> Victor,
> 
> 
>>So, we can propose new extension with new attribute where we can join
>>large attribute values or propose new RADIUS behaviour for VSA with
>>VendorId=0
> 
> 
> Having a large attribute ( > 255) will break all existing Radius implementations.
> Who ever sees this attribute ( be it Radius client, server or proxy) will need
> recoding which is bad.
> 
> Nagi.
	
Yes, but I don't say that we must increase attribute length.  We must 
propose method to join attribute values placed in different attributes 
with some "tag".  Like EAP for example.

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

Delivery-date: Mon, 16 Feb 2004 15:17:48 +0000
Date: Mon, 16 Feb 2004 18:17:18 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)

[email-masked] wrote:

> This is exactly why we need to ensure interoperability.  If we extend RADIUS in
> ways which would require RADIUS servers to be recoded, what is gained?  I think
> that if Extension X provides the exact same functionality as VSA y, what is 
> the need to support Extension X?  At in the GSMA, 3GPP, 3GPP2 and enterprise
> sphere, many vendors are implementing VSAs - even VSAs not specified by
> themselves.  I know in the enterprise sphere, vendors implement VSAs which 
> are specified by competitors all of the time.

I think that we must propose extensions for some service-specific areas 
to vendors may implemet it in their products.   So, SIP or WiFi specific 
attributes must be equal for all products from all vendors.

And because we have VSA and VendorId=0 treat as standard RADIUS we can 
use this to extend attribute space.  But current VSA has only 255 byte 
length attribute value. But new services require large attribute value 
sometimes.

So, we can propose new extension with new attribute where we can join 
large attribute values or propose new RADIUS behaviour for VSA with 
VendorId=0

IMHO

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

Delivery-date: Mon, 16 Feb 2004 15:08:12 +0000
Date: Mon, 16 Feb 2004 10:07:47 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: RADIUS and complex attributes

For some of the mechanisms that we need to support, we are going to have 
complex attributes with internal structure.  A good example is 
prepaid.  Given the complexities in prepaid, and the relationships among 
the information, flattening the full set of information into top level 
RADIUS attributes makes very little sense.

So what are the alternatives for problems that need to be carried in 
RADIUS, and require complex information.  I have seen the following suggested:

Flatten the attributes, use "tags" to tie the together.  While this works 
for some simple cases, it gets pretty hairy pretty quickly.

Let folks use VSAs.  One participant indicated that he did not see vendors 
saying that they would move from VSAs to standard attributes.  For many 
environments, there are very good reasons to prefer and move to 
standards.  The fact that we have to work with each RADIUS server vendor 
individually at each customer to get support for the VSAs we need for 
prepaid is NOT an advantage.  It would be worth the small amount of work to 
switch to switch our client to use standard attributes.  And I presume that 
the RADIUS server vendors would much prefer not to need a different 
implementation for each client that they have to work with.  Sticking with 
VSAs for widely need features is simply a mistake.

Allow complex attributes.  Call them subtypes if you like (or dislike) the 
point is that the information to be carried has internal structure and 
meaning.  It is very helpful if this structure can be standardized and 
described.  It seems highly desirable to do that at the IETF rather than 
separately at IEEE, 3GPP, 3GPP2, the DSL Forum, ...  And if we are going to 
do it at the IETF, this working group seems the right place to do this.

In trying to follow the argument against complex attribute values, it seems 
that the argument is that such things should not be allowed within RADIUS, 
but only when they are a "carried application".  It is understandable (and 
I support) that such attributes should not be mandatory for all clients or 
all servers, and that in general relays that are not adding value in the 
space of the complex attribute should be able to treat the attribute as a 
string.
Once that much is said, the discussion seems to devolve into an assertion 
that if it is a carried application than it must be some other working 
group, and that the RADIUSEXT working group should not be defining such 
applications.  Given that each of the applications is relatively small, and 
that unfortunately working groups carry a lot of overhead, it would simply 
seem more practical to define the extensions in the RADIUSEXT working group 
rather than trying to define a "prepaid" services WG and a "bandwidth 
allowance" working group, and...

Yours,
Joel M. Halpern

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

Delivery-date: Mon, 16 Feb 2004 14:22:22 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: subtypes (was: HTTP digest and RADIUS; new version of the Ste rman draft)
Date: Mon, 16 Feb 2004 15:22:17 +0100

John Loughney wrote:
> This is exactly why we need to ensure interoperability.  If we extend RADIUS in
> ways which would require RADIUS servers to be recoded, what is gained? 
Vendors keep adding minor extensions and fixes to their products all the time.
We have processes for sytem updates. Replacing a AAA platform is a different 
category.

> I think that if Extension X provides the exact same functionality as VSA y,
> what is the need to support Extension X?
If VSA is identical to Extension X, you are right. But what if VSA y does not
care about DIAMETER interopability and Extension X does? When I submitted
draft-sterman-aaa-sip, one of the first question was about DIAMETER
interopability. There was a problem that could be settled after some
discussion. In this particular case, we found that a change in the
DIAMETER SIP application draft was the best solution. With a VSA, this 
valuable discussion wouldn't have happened.

Wolfgang

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

Delivery-date: Mon, 16 Feb 2004 14:19:42 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: some comments on RADIUS Extension for Public Wireless LAN draft
Date: Mon, 16 Feb 2004 15:18:32 +0100

Hi all,
I would like to give some comments on the paper draft-adrangi-radius-extension-for-pwlan-00.txt

- General comment is that the list of attributes could be applicable for both Diameter and RADIUS (probably this has already been given).

- In chapter 2.1 one of the fields is Operator-name, and it is proposed to have a prefix with the operator type. If the Operator-name must be globally known and unique, why is it needed this prefix ? I guess the HSN will check the correctness of this Operator-name with some list it will have, so it will be easy to know of the operator is GSM, WISP, or whatever. This comment comes because if some operator has more than one type (GSM and WISP, for example), I guess its PWLAN ANs will always advertise the prefix WISP to the HSN (if not the same GSM operator, of course), since a reasonable roaming rule in an HSN could be to choose preferably PWLAN ANs not owned by other GSM operators (which are their competitors).
Other question about this attribute: how does this fit with the SSID ? Is it supposed to be copied into one of the fields ?

- Other attribute which may be interesting is the intermediate network identity. If the user is roaming in other country (or network) and there is an intermediate network which the traffic is traversing, the identity of such network would be interesting to have in the home network, for example for roaming restrictions control. Note that the roaming restrictions can be applied not only to the WLAN ANs but also to the intermediate networks. A AAA in the intermediate network would be in charge of inserting this parameter. The reason to have this parameter on purpose (and not use existing parameters) is that it avoids RADIUS/Diameter (or vice versa) conversion problems.

- For roaming restrictions control, it would be interesting to have something (if it does not exist) to indicate to the PWLAN client that roaming is not allowed in certain PWLAN ANs. For example, after a user has chosen one PWLAN AN (using the SSID or EAP methods currently being discussed), the PWLAN AN sends to the HSN the Operator-name and in the lists in the HSN that operator appears as "barred". The HSN has to send an access-reject so that a new PWLAN AN is chosen. Is it enough for this with the Reply-message attribute ? I think no, since a new network advertisement process has to be initiated.

- Other important aspect is to indicate to the WLAN AN from the HSN to allow/block certain services in the WLAN AN, for example direct internet access. If the HSN wants to charge the user for internet access, this can be done directly from the WLAN AN (but in that case the WLAN AN gets some revenues) or the HSN operator can force the user to access internet through the HSN (in that case the WLAN AN does not charge for it). So the HSN could indicate to the WLAN AN that direct internet access is not allowed for that user. Is it needed a new attribute for this, or an existing one can be used ?

Best regards,
David.

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

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

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

Delivery-date: Mon, 16 Feb 2004 13:30:40 +0000
content-class: urn:content-classes:message
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)
Date: Mon, 16 Feb 2004 15:30:34 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Wolfgang,

> Agreed. Can you give an example where the extension drafts would break
> your product?

As I haven't seen the need for the extensions, I haven't considered
them in any great detail.

> > Talking to other vendors, I haven't heard a lot of vendors saying =
that
> > they would move from VSAs to standard extensions if available.  On =
top
> > of that, several folks on this list have stated that other SDOs need
> > some extentions - if that is so, I think it would be good if those
> > SDOs would make it known to the IESG / this list via the liasons =
that
> > already exist.
>=20
> Providers (your customers) like standardized extensions better than
> vendor-specific ones. Else we have the choice between maintenance =
nightmare
> or vendors handcuffing us.

As far as I understand, many providers specify which VSAs they need =
supported.
Very rarely are they handcuffed to a particular supplier.

> > I think the IESG is looking for clear proof that RADIUS extensions =
are needed,
> > so I'd be interested in seeing some reasoning (perhaps even in draft
> > format) for this. Otherwise, I doubt the IESG will be really excited =
about
> > chartering this WG.  In otherwords, the burden of proof is upon =
those
> > who want to extend RADIUS.
>
> Like IPV6 migration, replacing RADIUS means replacing a platform, not =
just
> updating some systems.  Many providers can't afford to replace their =
AAA
> platform, just because it handles some error conditions nicer and is =
more
> extensible. The margins are pretty low in this business (not to =
mention the
> cash drain for buying Finnish 3G equipment).

This is exactly why we need to ensure interoperability.  If we extend =
RADIUS in
ways which would require RADIUS servers to be recoded, what is gained?  =
I think
that if Extension X provides the exact same functionality as VSA y, what =
is=20
the need to support Extension X?  At in the GSMA, 3GPP, 3GPP2 and =
enterprise
sphere, many vendors are implementing VSAs - even VSAs not specified by
themselves.  I know in the enterprise sphere, vendors implement VSAs =
which=20
are specified by competitors all of the time.
=20
> We still develop IPV4 protocols within the IETF.

And we also make sure that they are not IPv4 specific.

John

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

Delivery-date: Mon, 16 Feb 2004 13:20:52 +0000
content-class: urn:content-classes:message
Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman  draft)
Date: Mon, 16 Feb 2004 15:20:34 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Nagi,

> >  My company has implemented both, including some VSAs & we're =
concerned
> > about extensions that
> > would cause us to implement more stuff without a clear benefit for =
doing
> > so.
>=20
> Having a standard type doesn't necessarily mean to implement that. =
Right? A
> particular functionality like prepaid may not be supported by a box =
and still
> it can be a standard type.

My meta-point is really that if we are going to extend RADIUS, we should =
try
to extend RADIUS in such a way that doesn't break interoperability.  =
Additionally,
we need to sort out what are the extensions that are really needed.  I =
personally
don't have a sense of that yet.

John

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

Delivery-date: Mon, 16 Feb 2004 13:16:33 +0000
Date: Mon, 16 Feb 2004 14:16:10 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman  draft)

Hi John,

>  My company has implemented both, including some VSAs & we're concerned
> about extensions that
> would cause us to implement more stuff without a clear benefit for doing
> so.

Having a standard type doesn't necessarily mean to implement that. Right? A
particular functionality like prepaid may not be supported by a box and still
it can be a standard type.

Nagi.

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

Delivery-date: Mon, 16 Feb 2004 12:14:31 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: AW: subtypes (was: HTTP digest and RADIUS; new version of the Ste rman draft)
Date: Mon, 16 Feb 2004 13:14:21 +0100

> My two cents are that I hope extensions to RADIUS to not break current
> implementations of RADIUS and/or Diameter.  My company has implemented
> both, including some VSAs & we're concerned about extensions that
> would cause us to implement more stuff without a clear benefit
> for doing so.
Agreed. Can you give an example where the extension drafts would break
your product?

> Talking to other vendors, I haven't heard a lot of vendors saying that
> they would move from VSAs to standard extensions if available.  On top
> of that, several folks on this list have stated that other SDOs need
> some extentions - if that is so, I think it would be good if those
> SDOs would make it known to the IESG / this list via the liasons that
> already exist.
Providers (your customers) like standardized extensions better than
vendor-specific ones. Else we have the choice between maintenance nightmare
or vendors handcuffing us.

> I think we are between a rock & a hard place on this topic.  A few years
> ago, the IETF undertook a process to define the AAA infrastructure.  At
> the time, extending RADIUS seemed to be a messier job (and not guarenteed
> for success) than to standardize Diameter.  I think that the IETF did
> a poor job in getting Diameter completed in a timely manner (which
> is another source of the current mess we find ourselves in).
True. During that period we paid vendors to mitigate RADIUS deficiencies
using proprietary extensions. Which makes now DIAMETER migration even harder to
justify (not technically, but commercially).

> I think the IESG is looking for clear proof that RADIUS extensions are needed,
> so I'd be interested in seeing some reasoning (perhaps even in draft
> format) for this. Otherwise, I doubt the IESG will be really excited about
> chartering this WG.  In otherwords, the burden of proof is upon those
> who want to extend RADIUS.
Like IPV6 migration, replacing RADIUS means replacing a platform, not just
updating some systems.  Many providers can't afford to replace their AAA
platform, just because it handles some error conditions nicer and is more
extensible. The margins are pretty low in this business (not to mention the
cash drain for buying Finnish 3G equipment).

We still develop IPV4 protocols within the IETF.

Wolfgang

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

Delivery-date: Mon, 16 Feb 2004 12:10:35 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Mon, 16 Feb 2004 14:10:20 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Greg,

> This does seem like a good thing to discuss.  Seems to me that
> it would be beneficial to have some way of enforcing forward
> compatibility from RADIUS to Diameter.  A working group with
> both protocols in its purview might provide that venue for
> enforcement- or at least awareness.  Also, most of the work
> item areas are solution oriented, not protocol specific.=20
>=20
> I believe ITU-T is looking favorably at applying 3GPP's IMS
> architecture to DSL & Cable.  That leads me to believe that
> more Diameter applications will be on the way.  If AAA-WG is
> going to shutdown, we need an area for these new AAA applications
> to develop.

I agree with you on this point.  A question to the chairs -=20
should we send text on the proposed charter with this in mind?

thanks,
John

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

Delivery-date: Mon, 16 Feb 2004 10:48:34 +0000
content-class: urn:content-classes:message
Subject: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)
Date: Mon, 16 Feb 2004 12:48:29 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Wolfgang,

> We seem to have two main positions on the list on the purpose
> of RADIUSEXT. Correct me if I misunderstood the discussion.
>=20
> a) Only allow new attributes that can be introduced by just
> adding them to the dictionary and the user database. No
> recompilation of the RADIUS server is allowed.
>=20
> b) Add new attributes, even if they require some special server
> behaviour. The RADIUS protocol itself remains untouched. RADIUS server
> may need additional code to handle the new attributes.
>=20
> My suspicion is that our discussion is more about a) vs. b) than
> about attribute syntax.
>=20
> A charter only allowing a) is not really worth the effort, but seems
> to be preferred by people who want DIAMETER to be deployed.=20

My two cents are that I hope extensions to RADIUS to not break current
implementations of RADIUS and/or Diameter.  My company has implemented
both, including some VSAs & we're concerned about extensions that
would cause us to implement more stuff without a clear benefit
for doing so.

Talking to other vendors, I haven't heard a lot of vendors saying that
they would move from VSAs to standard extensions if available.  On top
of that, several folks on this list have stated that other SDOs need
some extentions - if that is so, I think it would be good if those
SDOs would make it known to the IESG / this list via the liasons that
already exist.

I think we are between a rock & a hard place on this topic.  A few years
ago, the IETF undertook a process to define the AAA infrastructure.  At
the time, extending RADIUS seemed to be a messier job (and not =
guarenteed
for success) than to standardize Diameter.  I think that the IETF did
a poor job in getting Diameter completed in a timely manner (which
is another source of the current mess we find ourselves in).   I think
the IESG is looking for clear proof that RADIUS extensions are needed,
so I'd be interested in seeing some reasoning (perhaps even in draft
format) for this. Otherwise, I doubt the IESG will be really excited =
about
chartering this WG.  In otherwords, the burden of proof is upon those
who want to extend RADIUS.

I'm not adverse to some extensions, I think some of the roaming
situations would be good places to create standards. However, my sense
of the room is that folks are saying we should extend RADIUS because
we can, which doesn't seem like a good argument.

John

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

Delivery-date: Mon, 16 Feb 2004 10:38:47 +0000
Date: Mon, 16 Feb 2004 11:38:22 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: "Nelson, David" <[email-masked]>
CC: [email-masked]
Subject: Subtypes

Chnaged the subject line from:  RE: FW: HTTP digest and RADIUS; new version
of the Sterman draft

> So are you saying that it's OK to treat a sub-class of RADIUS standard
> attributes as if they were VSAs, in that only RADIUS product from
> certain vendors who choose to support this functionality need to be able
> to parse the attributes?

It is OK to treat a sub-class of stabdard attributes as if they are not
relevant for this implementation. There are plenty of standard attributes
and one can't expect each and every implementation to support all of them.
Take for example, a Radius client implementation which doesn't understand
EAP messages. Let us say for instance, a malfunctioned Radius server
sending a EAP message to the non-EAP compliant Radius client as part of
Access-Accept. What do we expect from a Radius client?

- Just ignore the attribute and continue with the access-accept.
- Since it doesn't understand a standard attribute, it has to treat it as a
access-reject.

Ofcourse I vote for the first.

> I think an attribute is either of limited scope of application (a VSA),
> or it is of general applicability and all
> RADIUS implementations SHOULD understand it.

If it is not relevant for the implementation, it may ignore.

regards
Nagi.

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

Delivery-date: Mon, 16 Feb 2004 00:53:35 +0000
Date: Sun, 15 Feb 2004 19:53:25 -0500
To: Hannes Tschofenig <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: Re: draft-jones-radius-geopriv
Cc: [email-masked], [email-masked]

I am sorry I quoted the wrong part of RFC 2865.
The length of an attribute is at most 255, one octet [page 25].
It seems unlikely that GML, or any XML, would be efficient 
enough to be carried in a RADIUS attribute.

At 01:12 PM 2/10/2004, John Schnizlein wrote:
>> One concern, if this location configuration information (LCI)
>> is to be carried over RADIUS, is that the example in section 6
>> seems to be 993 characters long. This one attribute seems to be
>> taking a large share of the maximum RADIUS packet size of 4096.
>> [RFC 2865, p 15] Is there enough room for everything else that
>> would be expected with this attribute?

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

Delivery-date: Mon, 16 Feb 2004 00:23:12 +0000
Date: Mon, 16 Feb 2004 02:20:57 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Wolfgang Beck <[email-masked]>
CC: [email-masked]
Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft

Can we have a new subject line for the subtype debate? Right
now, I don't have time to follow that but I would like to follow
what is happening to the digest thing.

Thanks,

--Jari

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

Delivery-date: Sun, 15 Feb 2004 21:26:33 +0000
To: [email-masked]
Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sun, 15 Feb 2004 22:26:18 +0100
From: [email-masked] (Wolfgang Beck)

Dave Nelosn wrote:
> Wolfgang wrote:
>> A charter only allowing a) is not really worth the effort, but seems
>> to be preferred by people who want DIAMETER to be deployed.

> [DBN] In my case, I have no vested interest in the deployment of
> Diameter, so your inference here is debatable.
Sorry.

[DBN] I would turn your challenge around.  You have challenged us to
convince you that sub-types are "bad" for RADIUS.  I would challenge you
to demonstrate that sub-types do not alter the architectural intent of
standard RADIUS as it is documented.  A question of who bears the
"burden of proof".

OK, I'll try: RADIUS already uses already structured string
attributes. Some attributes (like CHAP-Password) simply group components
without delimiters. Some attributes use delimiters (like NAI). Some
attributes use a TLV syntax, like Vendor-Specific or EAP. draft-lior
and draft-sterman just followed existing examples. Nobody had the
intent to violate RADIUS principles. 

Many principles of RADIUS have been questioned and replaced, though.

> As to how to distinguish a sub-type from a compound, but
> opaque-to-RADIUS, data type, I think we have delineated that as closely
> as one can in general terms.  If a RADIUS client, proxy or server needs
> to parse the individual sub-fields of sub-types, then the sub-types
> ought to be flattened to the status of full attributes (or potentially
> flattened to the status of single-layer attributes under a VSA or SSA).
> The one counter-example is NAI parsing in proxies to determine the next
> hop server.
So, why don't you ask Jari to define a new Request-Destination
attribute?

> I would argue that QoS attributes, SIP attributes, pre-paid attributes,
> and the like are simply attributes.  The desire to "group" them can
> likely be handled by existing tagging methods.  Location attributes, if
> defined in some well-known format such as X.500 syntax, probably qualify
> as a single attribute, with multiple parts, similar to NAI in User-Names
> or FQDN in NAS-Identifiers.
The question is, whether an attribute can be used individually.  User-Name
makes sense in more than on combination. An HTTP digest nonce attribute
is useless if there aren't Method-, URI- etc attributes available.
HTTP groups them, why shouldn't RADIUS do the same?

And for your tunneling argument: how does flattening out attributes change
that? Would it be ok for you if we defined IP-Version, IP-Header-Length,
IP-Type-Of-Service etc attributes? I guess not.

Wolfgang

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

Delivery-date: Sun, 15 Feb 2004 21:25:56 +0000
From: Avi Lior <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Sun, 15 Feb 2004 16:25:42 -0500

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Monday, February 16, 2004 2:47 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft
> 
> 
> Avi Lior writes...
> 
> > Why is that any different then encoding a string with AVP
> as in X.500
> > encoding "a=1 b=3".  If that type of encoding is acceptable
> so should
> the
> > other.
> 
> [DBN] It IS different, and I don't know if I can come up with
> any additional or different explanations of why, beyond what 
> I have already written on this topic.  But let me try:  You 
> could, given the length constraints of attributes, create an 
> attribute of base-type undistinguished octets (String) and 
> include within the attribute value field an entire IPv4 
> packet.  

We are talking about RADIUS here right?  RADIUS attributes are limited to
253 Octets.  I don't see the relevance of your comment at all.

> We have one explicit example of an
> encapsulated protocol -- the EAP-Message attribute -- and 
> that's fine because it is reasonable, necessary and explicit. 
> It is also fine because EAP messages are clearly out-of-scope 
> for RADIUS.  No RADIUS product would want to attempt to parse 
> them -- they are "foreign" entities.

This is the exact case for Prepaid application and for Sterman draft. As you
correctly point out, just like the EAP case the internal attributes in both
the sterman draft and the prepaid draft are there exclusively for the
endpoint application.

As I suggested a million emails ago on this topic -- this should be the
test.  If the internal attributes are of use solely by the endpoint
applications (EAP for example) then there is no need to expose them.  Infact
there are advantages to be gained in performance gains in the proxy chains.
 
> The example you give in support of what I still call
> sub-types is X.500 addresses.  I have previously used a 
> similar example of DNS FQDNs.  Each of these is a multi-part 
> data type.  The distinction is that they are NOT a compendium 
> of attributes that are within the scope of AAA, grouped 
> together.  They are, to a large extent, an opaque data type 
> that the RADIUS protocol engine itself does not attempt to 
> parse.  They are forwarded to external entities, such as name 
> resolution engines, that process them, and potentially return 
> some useful result.  

Exactly correct. Once again this passes the above test.
Note that like in EAP endpoint application or foreign entities, or external
entities may be colocated with the RADIUS server or external to the RADIUS
server.  They are not part of the base RADIUS engine.

In past emails what I said was: If the protocol designer is allowed a
choice, it would be preferable that they use TLV encoding inside STRINGS as
opposed to "a=1  b=2" encoding scheme because of the obvious benefits of
being more compact and easier to parse.

>The only exception to this, that I'm
> aware of, is the NAI usages, in which a RADIUS proxy may 
> parse the "realm" portion of an NAI to determine the next hop 
> server address.

This is the minimum routing requirement and much more complex then you
indicate but I get your point and I agree.

> > The point which is made over and over is that the attribute
> is to be
> > interrperted only by endpoints and these would have code beyond the
> > dictionary anyway to parse further.
> 
> [DBN] I fully understand that point, however I reject it.
> This is not quite the same situation as the EAPOL messages we 
> encapsulate in EAP-Message attributes. The items being 
> debated are clearly, IMHO, AAA attributes fully within the 
> scope of RADIUS and Diameter.  Therefore any attempt to 
> "group" them in a fashion opaque to the majority of RADIUS 
> product simply fragments the multi-vendor interoperability of 
> RADIUS. The argument that only the RADIUS clients and servers 
> from companies that are promoting these proposals need to be 
> able to "play", i.e. to be able to parse the attributes if 
> they wish, is antithetical to the architecture of RADIUS.  
> Any such "limited scope" attributes MUST, IMHO, be VSAs.  
> Otherwise we no longer have a single, interoperable RADIUS standard.

I couldn't disagree with you more. First of all, the above argument has
nothing to do with with grouping attributes (or the creation of stealthy
protocols as you call it).  Its equally valid for ordinary RADIUS
attributes.  If I flatten out my "stealthy" attributes that doesn't mean
that everyone will implment them and should implment them!!!

And it's too late.  RADIUS already has the concept of extensions that are
not globally available or implemted by all RADIUS servers.

First there a groups of applications that are optionally supported:
EAP, CHIBA 3576, TUNNELS (2868), IPv6, WLAN extensions (RFC 3580)

Second there are many attributes that are optionally supported:

Look at all the Appletalk attributes.....

Not every deployment needs Appletalk 'stuff' and not every RADIUS client
supports these attributes. The same is true of EAP and the same could be
said of HTTP Digest.

You develop these extensions to that RADIUS can serve a purpose in an ever
evolving landscape.  You do this at the IETF for the obvious reasons.  

Mr Nelson, I am looking forward to you standing up at the next AAA-WG
meeting and objecting to having Diameter based Applications on the same
grounds.
 
> -- Dave
> 
> 
> 
> 

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

Delivery-date: Sun, 15 Feb 2004 20:29:06 +0000
content-class: urn:content-classes:message
Subject: RE: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sun, 15 Feb 2004 15:28:57 -0500
From: "Nelson, David" <[email-masked]>
To: "Wolfgang Beck" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> A charter only allowing a) is not really worth the effort, but seems
> to be preferred by people who want DIAMETER to be deployed.

[DBN] In my case, I have no vested interest in the deployment of
Diameter, so your inference here is debatable.=20

> I will remove structured strings immediately from
draft-sterman-aaa-sip
> if somebody can show me a concrete real world example why they are so
> horrible. The debate on "tunneling" and secondary issues like
attribute
> syntax is somewhat philosophical and leads nowhere. Every protocol
tunnels
> higher layer protocols. Jari's 'user@realm' tunnels request-routing
> information in a User-Name attribute. The Digest-Attributes attribute
> of draft-sterman-aaa-sip tunnels HTTP digest information, using a TLV
> syntax instead of '@' for separating optional components. Where do you
> draw the line and why?

[DBN] I would turn your challenge around.  You have challenged us to
convince you that sub-types are "bad" for RADIUS.  I would challenge you
to demonstrate that sub-types do not alter the architectural intent of
standard RADIUS as it is documented.  A question of who bears the
"burden of proof".

As to how to distinguish a sub-type from a compound, but
opaque-to-RADIUS, data type, I think we have delineated that as closely
as one can in general terms.  If a RADIUS client, proxy or server needs
to parse the individual sub-fields of sub-types, then the sub-types
ought to be flattened to the status of full attributes (or potentially
flattened to the status of single-layer attributes under a VSA or SSA).
The one counter-example is NAI parsing in proxies to determine the next
hop server.

I would argue that QoS attributes, SIP attributes, pre-paid attributes,
and the like are simply attributes.  The desire to "group" them can
likely be handled by existing tagging methods.  Location attributes, if
defined in some well-known format such as X.500 syntax, probably qualify
as a single attribute, with multiple parts, similar to NAI in User-Names
or FQDN in NAS-Identifiers.

-- Dave

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

Delivery-date: Sun, 15 Feb 2004 19:54:47 +0000
To: [email-masked]
Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sun, 15 Feb 2004 20:54:04 +0100
From: [email-masked] (Wolfgang Beck)

We seem to have two main positions on the list on the purpose
of RADIUSEXT. Correct me if I misunderstood the discussion.

a) Only allow new attributes that can be introduced by just
adding them to the dictionary and the user database. No
recompilation of the RADIUS server is allowed.

b) Add new attributes, even if they require some special server
behaviour. The RADIUS protocol itself remains untouched. RADIUS server
may need additional code to handle the new attributes.

My suspicion is that our discussion is more about a) vs. b) than
about attribute syntax.

A charter only allowing a) is not really worth the effort, but seems
to be preferred by people who want DIAMETER to be deployed. 

I'd prefer a charter that allows b) and so do some other draft authors.
To those who support a), would your vote be the same if we were discussing
a AAAEXT charter and were talking about DIAMETER AVPs?

Dave Nelson wrote:
> My further opinion is that much of the argument in favor of sub-types is
> seeking to protect existing implementations from IETF WG change control.
I will remove structured strings immediately from draft-sterman-aaa-sip
if somebody can show me a concrete real world example why they are so
horrible. The debate on "tunneling" and secondary issues like attribute
syntax is somewhat philosophical and leads nowhere. Every protocol tunnels
higher layer protocols. Jari's 'user@realm' tunnels request-routing
information in a User-Name attribute. The Digest-Attributes attribute
of draft-sterman-aaa-sip tunnels HTTP digest information, using a TLV
syntax instead of '@' for separating optional components. Where do you
draw the line and why?

Wolfgang

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

Delivery-date: Sun, 15 Feb 2004 18:04:10 +0000
content-class: urn:content-classes:message
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sun, 15 Feb 2004 13:04:03 -0500
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

>   One of the reasons for writing standards in the IETF is so that
> other people don't.  As we've seen in a number of cases, non-IETF
> extensions to RADIUS involve *terrible* protocol design.

[DBN] Agreed.=20

>   I'm sure many people will agree that defining sub-types in RADIUS is
> ugly.  But it's significantly less ugly than the choices made by
> non-IETF groups.

[DBN] Hmmm.  That may amount to damnation by means of faint praise.  :-)

>   The single largest reason for defining sub-types is not to make our
> life easier when writing new I-D's for RADIUS.  It's to give other
> people a standard way of extending RADIUS, and thus to make our life
> easier when we have to implement their modifications to the protocol.

[DBN] My personal opinion on this is that the sub-types are not in any
technical way necessary in any of these current proposals.   The
authors, working outside of IETF supervision, have created, implemented,
and in some cases deployed, these extensions using sub-types.  My
further opinion is that much of the argument in favor of sub-types is
seeking to protect existing implementations from IETF WG change control.

There may, in fact, be some merit to a variation of your suggestion.  I
have thought about the notion of SDO-Specific RADIUS Attributes (SSAs).
These would be structured similarly to the VSAs, but with the
requirement of a single layer of sub-attributes, reflecting standard
RADIUS attribute format within the value field of an SSA, promoted to a
MUST.  This would allow SDOs to create RADIUS attributes within their
"vendor ID" space.  In addition, there should be some formal protocol
quality review process, similar to the "MIB Doctors" used to review new
MIBs.  All of this would not help the current debate, however, as
"grouped" sub-types would still be prohibited.  But it might be of great
utility for future discussions.

-- Dave

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

Delivery-date: Sun, 15 Feb 2004 17:46:46 +0000
content-class: urn:content-classes:message
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Sun, 15 Feb 2004 12:46:35 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> Why is that any different then encoding a string with AVP as in X.500
> encoding "a=3D1 b=3D3".  If that type of encoding is acceptable so =
should
the
> other.

[DBN] It IS different, and I don't know if I can come up with any
additional or different explanations of why, beyond what I have already
written on this topic.  But let me try:  You could, given the length
constraints of attributes, create an attribute of base-type
undistinguished octets (String) and include within the attribute value
field an entire IPv4 packet.  I think it is clear, in this somewhat
extreme example, that a string is not a simple string but a "stealth
protocol".  I am opposed to hiding "stealth protocols" in RADIUS
attributes.  We have one explicit example of an encapsulated protocol --
the EAP-Message attribute -- and that's fine because it is reasonable,
necessary and explicit. It is also fine because EAP messages are clearly
out-of-scope for RADIUS.  No RADIUS product would want to attempt to
parse them -- they are "foreign" entities.

The example you give in support of what I still call sub-types is X.500
addresses.  I have previously used a similar example of DNS FQDNs.  Each
of these is a multi-part data type.  The distinction is that they are
NOT a compendium of attributes that are within the scope of AAA, grouped
together.  They are, to a large extent, an opaque data type that the
RADIUS protocol engine itself does not attempt to parse.  They are
forwarded to external entities, such as name resolution engines, that
process them, and potentially return some useful result.  The only
exception to this, that I'm aware of, is the NAI usages, in which a
RADIUS proxy may parse the "realm" portion of an NAI to determine the
next hop server address.

> The point which is made over and over is that the attribute is to be
> interrperted only by endpoints and these would have code beyond the
> dictionary anyway to parse further.

[DBN] I fully understand that point, however I reject it.  This is not
quite the same situation as the EAPOL messages we encapsulate in
EAP-Message attributes. The items being debated are clearly, IMHO, AAA
attributes fully within the scope of RADIUS and Diameter.  Therefore any
attempt to "group" them in a fashion opaque to the majority of RADIUS
product simply fragments the multi-vendor interoperability of RADIUS.
The argument that only the RADIUS clients and servers from companies
that are promoting these proposals need to be able to "play", i.e. to be
able to parse the attributes if they wish, is antithetical to the
architecture of RADIUS.  Any such "limited scope" attributes MUST, IMHO,
be VSAs.  Otherwise we no longer have a single, interoperable RADIUS
standard.

-- Dave

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

Envelope-to: [email-masked]
Delivery-date: Sun, 15 Feb 2004 17:14:11 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sun, 15 Feb 2004 12:16:22 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> In general, the server does not need to understand attributes that it
> sends, although the NAS does need to understand those it receives.
> If the server is sending an attribute it doesn't understand, why should
> the server require code changes?

  For attributes like IP addresses, text strings, or integers, I agree.

  For attributes which require some kind of calculation (e.g. md5, or
authentication calculations), the server *must* be upgraded.

> While one could argue that the server could just create a "String" type,
> the reality is that many RADIUS implementations don't support entering
> arbitrary binary data into "String" attribute types.

  Which is an implementation limitation, in *addition* to those
imposed by the RFC's.  Many attributes are defined or suggested to be
"undistinguished octets".  If a server does not support that, I don't
see why it would be fully RFC compliant.  And I don't see why we would
handcuff ourselves for new attributes, just because of non-compliant
implementations.  There's a simple solution: upgrade.

> Do we have concrete examples of where this will *not* work?

  My previous post mentioned IP addresses.  They also won't work (or
will be difficult) when the encapsulated data is undistinguished
octets.  If the first octet is 0x01, is it a tag, or part of the
atribute data?

  I've always thought that the design of tagged attributes was
problematic.  The tags may, or may not, exist.  The value in the first
octet may, or may not, be a tag.  You can't have tagged IP addresses.
Tagged integers can only be 24 bits, etc.

  All of these limitations and different ways of doing the same thing
make implementation more difficult.  I'm not a party to any draft
which proposes new attributes, but I will be implementing support for
them.  Being lazy, I'd rather see an attribute design which has a
simple implementation, than one which gives me 2-4 ways of doing the
same thing, and also prevents me from doing other things which are
currently possible.

  Alan DeKok.

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

Delivery-date: Sat, 14 Feb 2004 17:56:29 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sat, 14 Feb 2004 12:56:25 -0500

Thank you for the reply.  Here is my follow up.

Can you show me in either sterman or lior where we are adding a new type to
RADIUS?

The encoding used for the string attributes may be functinally equivalent to
a Grouped attribute but its not the same because we are not seeking to
create a new attribute. If we were creating a grouped type then code would
have to change because RADIUS dictionaries know about string and don't know
about Grouped AVPs.

So specifically, sterman/lior do not break RADIUS dictionaries. Right?

Passing this attributes over a proxy chain today will not create a problem
right?  No new code would have to be introduced to handle these attributes.

I wish to debate the pros and cons of introducing an Grouped AVPs but I
don't want that debate to get in the way of the specific case. (At least in
this email).

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: February 14, 2004 12:19 PM
> To: Avi Lior
> Cc: Alan DeKok; [email-masked]
> Subject: RE: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft 
> 
> 
> > While this debate is interesting its not addressing the 
> issue. We are 
> > not trying to create a new fundemental type!  We agree That 
> this would 
> > break RADIUS.
> >
> > Sterman draft and my prepaid draft are not introducing any new 
> > fundemental type. We are introducing a new Attribute of Type String.
> >
> > Given that, that this is only to be decoded at the RADIUS 
> server for 
> > which the Attribute is intended (and not by proxies) then how does 
> > this break existing RADIUS Server?
> 
> This is the equivalent to Diameter's Grouped AVPs.  Note that 
> grouping is allowed within RFC 2865 only for attributes of 
> Type 26 (Vendor Specific).  In Section 5.26, it states:
> 
> "     Multiple subattributes MAY be encoded within a single Vendor-
>       Specific attribute, although they do not have to be."
> 
> Grouped AVPs do not violate the fundamental design principle 
> of Diameter, since a Diameter server is assumed to be able to 
> handle the addition of a Grouped AVP without code changes.
> 
> However, some constraints are required to limit the resulting 
> complexity. Diameter Grouped AVPs prohibit nesting within 
> sub-types (e.g. no Grouped AVP within a Grouped AVP), and 
> permit sub-AVPs only to utilize one of the Types defined in Diameter.
> 
> That said, there are some additional constraints that appear 
> in RADIUS.
> 
> a. Efficiency.  The "tagged" approach taken in RFC 2867 and 
> 2868 is more efficient than Grouped AVPs, and therefore is 
> probably to be preferred, everything else being equal.  Do we 
> have examples where the "tagged" approach would not work?
> 
> b. Length constraints.  Unlike Diameter, RADIUS attributes 
> can only be 253 octets in length.  If Grouped AVPs are in 
> aggregate longer than this, then it will be necessary to 
> support fragmentation and reassembly of Grouped AVPs which 
> increases complexity.
> 

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

Delivery-date: Sat, 14 Feb 2004 17:51:02 +0000
Date: Sat, 14 Feb 2004 10:02:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 

>   ... new VSA-style attributes with sub-types can be ignored by
> servers that don't understand them.  Provisions for this behaviour are
> already in the RFC's.  This makes adding new attributes easy, whatever
> their internal format.

The issue isn't just for receivers.  It is also for servers *sending* the
attributes.

> attributes is irrelevant to anyone not implementing support for them.

In general, the server does not need to understand attributes that it
sends, although the NAS does need to understand those it receives.
If the server is sending an attribute it doesn't understand, why should
the server require code changes?

While one could argue that the server could just create a "String" type,
the reality is that many RADIUS implementations don't support entering
arbitrary binary data into "String" attribute types.

> I don't see anyone here trying to create a data definition language
> for RADIUS.  That's a bit much.  The only debate I've seen so far is
> about the ability to have VSA-style sub-types in new attributes.

In Diameter, grouped AVPs are not allowed except where the AVPs being
grouped have some relationship to each other.  So is the issue really
grouping, or is it the need for new types (such as a 128-bit IPv6 address
type).  If the former, do we understand why the tagging approach proposed
in RFC 2867 and 2868 won't work?

> I agree that this will be sufficient for many situations.

Do we have concrete examples of where this will *not* work?

BTW, it's important in this discussion to distinguish between "tagging",
grouped AVPs and additional datatype proposals.  Each of these approaches
has quite different implications.

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

Envelope-to: [email-masked]
Delivery-date: Sat, 14 Feb 2004 17:30:42 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sat, 14 Feb 2004 12:33:14 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> a. Efficiency.  The "tagged" approach taken in RFC 2867 and 2868 is
> more efficient than Grouped AVPs, and therefore is probably to be
> preferred, everything else being equal.  Do we have examples where the
> "tagged" approach would not work?

  Anywhere an IP address is required to be a member of a group.

  Even RFC 2868 hides this problem:

---
   Type
      66 for Tunnel-Client-Endpoint.
...
   String
      The format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IPv4 (1), then this string is either the
      fully qualified domain name (FQDN) of the tunnel client machine,
      or it is a "dotted-decimal" IP address.
---

  My only response is "yuck".  I understand why that was done, but
RADIUS already has an "IP address" fundamental data type.  It would
have been cleaner to define a "Tunnel-Client-Endpoint-IP-Address"
attribute, but that's impossible with the "tag" method of grouping
attributes.

  In this case, the goal for backwards compatibility resulted in the
addition of a *new* base type to RADIUS: IP addresses represented in
text as dotted quads, rather than as 32-bit entities.  It would have
arguable been cleaner to group the attributes into a new
"Tunnel-Message" attribute, like EAP-Message, but with VSA-style
sub-types.  But I don't want to get into re-designing those RFC's now.

> b. Length constraints.  Unlike Diameter, RADIUS attributes can only be 253
> octets in length.  If Grouped AVPs are in aggregate longer than this, then
> it will be necessary to support fragmentation and reassembly of
> Grouped AVPs which increases complexity.

  That is an issue.  But People have dealt with it for EAP-Message, so
I don't see any real difficulties with it.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Sat, 14 Feb 2004 17:19:12 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sat, 14 Feb 2004 12:21:46 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> One of the basic design principles of RADIUS is that adding a new
> attributes does not require code changes on the server.  To maintain this
> principle while adding sub-types is extremely difficult because:

  ... new VSA-style attributes with sub-types can be ignored by
servers that don't understand them.  Provisions for this behaviour are
already in the RFC's.  This makes adding new attributes easy, whatever
their internal format.

  I just don't see concrete reasons to oppose the idea that new
attributes may be interpreted in certain limited ways by servers which
have support for those attributes.  Whatever goes into those
attributes is irrelevant to anyone not implementing support for them.

> a.  RADIUS attributes are of limited length.  In Diameter, attributes can
> be much larger, which allowed us to introduce "Grouped" AVPs. However,
> "Grouped" attributes are permitted in RFC 2865 only within attribute
> 26, Vendor-Specific, but they are of limited utility since in RADIUS
> an attribute can only be 253 octets in length.

  There's nothing to stop us from treating sequential instances of the
same attribute in the same way as we now deal with EAP-Message.  The
only limit on encapsulated data is RADIUS packet size.  Existing
implementations don't need to change.

> b. AAA protocols have chosen not to introduce a data definition language
> such as the SMI.  This was debated in the AAA WG, but it was decided that
> this would introduce a level of complexity that was not warranted.  In any
> case, now that Diameter has chosen grouped AVPs, introduction of a data
> type definition language in RADIUS would introduce compatibility issues.

  I don't see anyone here trying to create a data definition language
for RADIUS.  That's a bit much.  The only debate I've seen so far is
about the ability to have VSA-style sub-types in new attributes.

> Given the constraints implied by a) and b), the traditional approach in
> RADIUS has been to introduce "tagged" attributes that fit within existing
> data types.  For example, RFC 2867 and 2868 utilize tags within 4-octet
> integers, so that no new data types are required.

  I agree that this will be sufficient for many situations.  If there
is huge opposition to sub-types, then draft authors may trivially work
around the problem by defining "tagged" attributes, where the "tag" is
interpreted as a sub-type.  There will be no changes to existing
implementations, and the attributes will fit into the current
requirements.

  Would that solution be more, or less, acceptable than defining
VSA-style sub-types in a new attribute?

  Alan DeKok.

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

Delivery-date: Sat, 14 Feb 2004 17:07:22 +0000
Date: Sat, 14 Feb 2004 09:19:20 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 

> While this debate is interesting its not addressing the issue.
> We are not trying to create a new fundemental type!  We agree
> That this would break RADIUS.
>
> Sterman draft and my prepaid draft are not introducing any new
> fundemental type. We are introducing a new Attribute of
> Type String.
>
> Given that, that this is only to be decoded at the RADIUS
> server for which the Attribute is intended (and not by proxies)
> then how does this break existing RADIUS Server?

This is the equivalent to Diameter's Grouped AVPs.  Note that
grouping is allowed within RFC 2865 only for attributes of Type 26 (Vendor
Specific).  In Section 5.26, it states:

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

Grouped AVPs do not violate the fundamental design principle of Diameter,
since a Diameter server is assumed to be able to handle the addition of a
Grouped AVP without code changes.

However, some constraints are required to limit the resulting complexity.
Diameter Grouped AVPs prohibit nesting within sub-types (e.g. no Grouped
AVP within a Grouped AVP), and permit sub-AVPs only to utilize one of the
Types defined in Diameter.

That said, there are some additional constraints that appear in RADIUS.

a. Efficiency.  The "tagged" approach taken in RFC 2867 and 2868 is
more efficient than Grouped AVPs, and therefore is probably to be
preferred, everything else being equal.  Do we have examples where the
"tagged" approach would not work?

b. Length constraints.  Unlike Diameter, RADIUS attributes can only be 253
octets in length.  If Grouped AVPs are in aggregate longer than this, then
it will be necessary to support fragmentation and reassembly of
Grouped AVPs which increases complexity.

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

Delivery-date: Sat, 14 Feb 2004 16:33:57 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sat, 14 Feb 2004 11:33:43 -0500

Bernard,

While this debate is interesting its not addressing the issue.
We are not trying to create a new fundemental type!  We agree
That this would break RADIUS.

Sterman draft and my prepaid draft are not introducing any new=20
fundemental type. We are introducing a new Attribute of
Type String.

Given that, that this is only to be decoded at the RADIUS=20
server for which the Attribute is intended (and not by proxies)=20
then how does this break existing RADIUS Server? =20

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

   Type

      TBD for Digest-Attributes.

   Length

      >=3D 5

   String

      The  String  field  is 3 or more octets and contains one or
      more subattributes. Format of a subattribute is  shown  be=A1
      low. The fields are transmitted from left to right.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |     Sub-Type  |  Sub-Length   | Sub-Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

       .........................

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: February 14, 2004 10:27 AM
> To: Alan DeKok
> Cc: [email-masked]
> Subject: Re: FW: HTTP digest and RADIUS; new version of the=20
> Sterman draft=20
>=20
>=20
> > The single largest reason for defining sub-types is not to make our =

> > life easier when writing new I-D's for RADIUS.  It's to give other=20
> > people a standard way of extending RADIUS, and thus to make=20
> our life=20
> > easier when we have to implement their modifications to the=20
> protocol.
>=20
> One of the basic design principles of RADIUS is that adding a=20
> new attributes does not require code changes on the server. =20
> To maintain this principle while adding sub-types is=20
> extremely difficult because:
>=20
> a.  RADIUS attributes are of limited length.  In Diameter,=20
> attributes can be much larger, which allowed us to introduce=20
> "Grouped" AVPs. However, "Grouped" attributes are permitted=20
> in RFC 2865 only within attribute 26, Vendor-Specific, but=20
> they are of limited utility since in RADIUS an attribute can=20
> only be 253 octets in length.
>=20
> b. AAA protocols have chosen not to introduce a data=20
> definition language such as the SMI.  This was debated in the=20
> AAA WG, but it was decided that this would introduce a level=20
> of complexity that was not warranted.  In any case, now that=20
> Diameter has chosen grouped AVPs, introduction of a data type=20
> definition language in RADIUS would introduce compatibility issues.
>=20
> Given the constraints implied by a) and b), the traditional=20
> approach in RADIUS has been to introduce "tagged" attributes=20
> that fit within existing data types.  For example, RFC 2867=20
> and 2868 utilize tags within 4-octet integers, so that no new=20
> data types are required.
>=20
> Another potential approach would be to add additional=20
> fundamental types, such as 128-bit IPv6 addresses.  While=20
> code changes would be required, they would presumably only=20
> need to be done once, and the basic RADIUS design principle=20
> would be upheld.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Sat, 14 Feb 2004 15:15:13 +0000
Date: Sat, 14 Feb 2004 07:26:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 

> The single largest reason for defining sub-types is not to make our
> life easier when writing new I-D's for RADIUS.  It's to give other
> people a standard way of extending RADIUS, and thus to make our life
> easier when we have to implement their modifications to the protocol.

One of the basic design principles of RADIUS is that adding a new
attributes does not require code changes on the server.  To maintain this
principle while adding sub-types is extremely difficult because:

a.  RADIUS attributes are of limited length.  In Diameter, attributes can
be much larger, which allowed us to introduce "Grouped" AVPs. However,
"Grouped" attributes are permitted in RFC 2865 only within attribute
26, Vendor-Specific, but they are of limited utility since in RADIUS
an attribute can only be 253 octets in length.

b. AAA protocols have chosen not to introduce a data definition language
such as the SMI.  This was debated in the AAA WG, but it was decided that
this would introduce a level of complexity that was not warranted.  In any
case, now that Diameter has chosen grouped AVPs, introduction of a data
type definition language in RADIUS would introduce compatibility issues.

Given the constraints implied by a) and b), the traditional approach in
RADIUS has been to introduce "tagged" attributes that fit within existing
data types.  For example, RFC 2867 and 2868 utilize tags within 4-octet
integers, so that no new data types are required.

Another potential approach would be to add additional fundamental types,
such as 128-bit IPv6 addresses.  While code changes would be required,
they would presumably only need to be done once, and the basic RADIUS
design principle would be upheld.

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

Envelope-to: [email-masked]
Delivery-date: Sat, 14 Feb 2004 11:04:14 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Sat, 14 Feb 2004 06:06:31 -0500
Message-Id: <[email-masked]>

Greg Weber <[email-masked]> wrote:
> One advantage of formalizing sub-typed data might be to imposing
> or strongly encouraging that same structured framework on VSAs.  
> I'm fearful of heading towards lots of different VSA structures, 
> e.g. IS-835 has at least a couple different VSA-specific ways 
> of sub-typing data.

  Similarly for the 3gpp2 attributes.

  One of the reasons for writing standards in the IETF is so that
other people don't.  As we've seen in a number of cases, non-IETF
extensions to RADIUS involve *terrible* protocol design.

  I'm sure many people will agree that defining sub-types in RADIUS is
ugly.  But it's significantly less ugly than the choices made by
non-IETF groups.

  The single largest reason for defining sub-types is not to make our
life easier when writing new I-D's for RADIUS.  It's to give other
people a standard way of extending RADIUS, and thus to make our life
easier when we have to implement their modifications to the protocol.

  Alan DeKok.

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

Delivery-date: Sat, 14 Feb 2004 09:31:39 +0000
From: Avi Lior <[email-masked]>
To: 'Nagi' <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Sat, 14 Feb 2004 04:31:06 -0500

Thanx NAGI,

With one comment which I think is important.  Its not a single unknown TLV.
The attribute is of type String.

The proxy would not see an unknown attribute.  It would see an attribute of
type string which it wouldn't know how to generally parse further.

> -----Original Message-----
> From: Nagi [mailto:[email-masked]] 
> Sent: February 13, 2004 11:57 AM
> To: Nelson, David
> Cc: Alan DeKok; [email-masked]
> Subject: Re: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft
> 
> 
> >  I argue that adding sub-types means changing the parsing code.
> 
> *only* the end points who wish to understand the sub-types 
> need to implement the parsing code ( almost similar to VSA 
> parsing). Radius proxies
> treat these sub-types as a single unknown TLV.   That is 
> acceptable, IMO.
> 
> -Nagi.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Fri, 13 Feb 2004 19:09:46 +0000
Date: Fri, 13 Feb 2004 11:21:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 

> If tagged attributes are sufficient, then I see no reason to add new
> sub-types.

Note that RFC 2867 and 2868 make use of "tagged" attributes.  These RFCs
do *not* define sub-types because the attributes are designed to fit
within an existing data type - 4-octet Integer.

Having said that, new code typically *was* required to implement RFC 2867
and 2868, so as to allow the creation of UI to enable entering of Tunnel
attributes in an easy-to-use way.  However, existing products could have
been used without code changes, by manually entering appropriate
Integer values.

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

Delivery-date: Fri, 13 Feb 2004 19:05:02 +0000
Date: Fri, 13 Feb 2004 11:15:13 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Nagi <[email-masked]>, [email-masked]
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft

> Recall that RADIUS clients MAY handle an unknown
> attribute by treating the packet as if it were an Access-Reject.

RFC 2865 Section 1.1 says:

   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
   unavailable service as an access-reject instead.

At the same time, Section 5 says:

      A RADIUS server MAY ignore Attributes with an unknown Type.
      A RADIUS client MAY ignore Attributes with an unknown Type.

My interpretation of this is that RFC 2865 defines attributes authorizing
a service as "mandatory", whereas other attributes are optional.  The next
question is "which attributes advertise a service?"  The definition of a
service in RFC 2865 is:

   service   The NAS provides a service to the dial-in user, such as PPP
             or Telnet.

This example seems to correspond to the definition of the Service-Type
attribute (which can authorize Framed or Login services, among others).
So at least the Service-Type attribute needs to be considered Mandatory.

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

Delivery-date: Fri, 13 Feb 2004 18:27:16 +0000
content-class: urn:content-classes:message
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Fri, 13 Feb 2004 13:26:53 -0500
From: "Nelson, David" <[email-masked]>
To: "Nagi" <[email-masked]>
Cc: <[email-masked]>

Nagi writes...

> *only* the end points who wish to understand the sub-types need to
> implement the parsing code ( almost similar to VSA parsing). Radius
> proxies treat these sub-types as a single unknown TLV.   That is
> acceptable, IMO.

I guess as long as the policy is to blithely ignore unknown attributes.
That might be an acceptable policy for a proxy, under certain
circumstances.  Recall that RADIUS clients MAY handle an unknown
attribute by treating the packet as if it were an Access-Reject.

There is almost always a policy decision to be made between the
interests of transparent plug and play and the interests of strict
security.

So are you saying that it's OK to treat a sub-class of RADIUS standard
attributes as if they were VSAs, in that only RADIUS product from
certain vendors who choose to support this functionality need to be able
to parse the attributes?  I think an attribute is either of limited
scope of application (a VSA), or it is of general applicability and all
RADIUS implementations SHOULD understand it.

-- Dave

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

Delivery-date: Fri, 13 Feb 2004 17:24:30 +0000
From: Greg Weber <[email-masked]>
Subject: Re: Bof at next IETF?
To: [email-masked]
Date: Fri, 13 Feb 2004 12:24:03 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> > >But at the last meeting, I remember 
> > > that a significant number of people thought it would be best 
> > > for the WG to be AAA Extensions, not just RADIUS extensions, 
> > > but we haven't discussed that on the mailing list.

This does seem like a good thing to discuss.  Seems to me that
it would be beneficial to have some way of enforcing forward
compatibility from RADIUS to Diameter.  A working group with
both protocols in its purview might provide that venue for
enforcement- or at least awareness.  Also, most of the work
item areas are solution oriented, not protocol specific. 

I believe ITU-T is looking favorably at applying 3GPP's IMS
architecture to DSL & Cable.  That leads me to believe that
more Diameter applications will be on the way.  If AAA-WG is
going to shutdown, we need an area for these new AAA applications
to develop.

Greg

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

Delivery-date: Fri, 13 Feb 2004 16:57:37 +0000
Date: Fri, 13 Feb 2004 17:57:21 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: "Nelson, David" <[email-masked]>
CC: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft

>  I argue that adding sub-types means changing the parsing code.

*only* the end points who wish to understand the sub-types need to
implement the parsing code ( almost similar to VSA parsing). Radius proxies
treat these sub-types as a single unknown TLV.   That is acceptable, IMO.

-Nagi.

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

Delivery-date: Fri, 13 Feb 2004 16:31:32 +0000
From: Greg Weber <[email-masked]>
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft
To: [email-masked] (Nelson, David)
Date: Fri, 13 Feb 2004 11:31:09 -0500 (EST)
Cc: [email-masked] (Alan DeKok), [email-masked]

> 
> Alan DeKok writes...
> 
> > > The technical arguments that I have heard (and advanced) against
> > > sub-types are that it changes the RADIUS architecture (simple TLV
> > > structures), requires changes to the RADIUS dictionary, and breaks
> > > backwards compatibility with a large deployed base of RADIUS
> products.
> > 
> >   ... which we already know won't understand the new attributes.
> 
> Yes, but they could by updating their dictionary file (or equivalent
> dictionary implementation).  I guess that was the point of my admittedly
> imperfect analogy with SNMP -- data dictionary driven protocol parsing,
> as opposed to code driven parsing.  I argue that adding sub-types means
> changing the parsing code.  

Catching up on this discussion... Would the code changes you 
mention be necessary for all RADIUS endpoints or only those
that wish to understand sub-typed attributes?  I would think
that sub-typed data (as in Diameter) could be structured to
look like a regular attribute at the highest level. And at 
that level these attributes would be ignored by endpoints 
that don't have definitions for them.  That would seem to
indicate that sub-typed data could be compatible with existing
devices, but code changes would be necessary to take advantage
of the new attributes.  As to the code changes, I would imagine
that most RADIUS client/servers already have code to parse 
structured values as many VSA values have structured data.

One advantage of formalizing sub-typed data might be to imposing
or strongly encouraging that same structured framework on VSAs.  
I'm fearful of heading towards lots of different VSA structures, 
e.g. IS-835 has at least a couple different VSA-specific ways 
of sub-typing data.

Greg

> RADIUS implementations have been designed
> from day-one to deal with new attributes, in the standard single-layer
> TLV format.
> 
> I do understand that a NAS or RADIUS server that actually wants to do
> something useful with the semantics of a new attribute will need added
> or changed code somewhere, even if not in the core RADIUS protocol
> engine.
> 
> >   The only hard requirement I can see for backwards compatibility is
> > that old servers MUST be able to act as proxies for requests with new
> > attributes.  We've seen this behaviour with EAP-Message, so we know it
> > works.
> 
> I suppose I draw a distinction that not everyone will agree with.  EAPOL
> frames are not RADIUS attributes in the classic sense of the definition.
> I see tunneling EAP in RADIUS as a natural thing to do.  Many of the
> other proposed new attributes seem like any other RADIUS attribute to
> me, and thus I resist the notion of tunneling, or sub-typing.
> 
> >   If tagged attributes are sufficient, then I see no reason to add new
> > sub-types.
> 
> That works for me.  Let's see if it works for others.
> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Fri, 13 Feb 2004 16:06:25 +0000
content-class: urn:content-classes:message
Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Fri, 13 Feb 2004 11:05:41 -0500
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

> > The technical arguments that I have heard (and advanced) against
> > sub-types are that it changes the RADIUS architecture (simple TLV
> > structures), requires changes to the RADIUS dictionary, and breaks
> > backwards compatibility with a large deployed base of RADIUS
products.
>=20
>   ... which we already know won't understand the new attributes.

Yes, but they could by updating their dictionary file (or equivalent
dictionary implementation).  I guess that was the point of my admittedly
imperfect analogy with SNMP -- data dictionary driven protocol parsing,
as opposed to code driven parsing.  I argue that adding sub-types means
changing the parsing code.  RADIUS implementations have been designed
from day-one to deal with new attributes, in the standard single-layer
TLV format.

I do understand that a NAS or RADIUS server that actually wants to do
something useful with the semantics of a new attribute will need added
or changed code somewhere, even if not in the core RADIUS protocol
engine.

>   The only hard requirement I can see for backwards compatibility is
> that old servers MUST be able to act as proxies for requests with new
> attributes.  We've seen this behaviour with EAP-Message, so we know it
> works.

I suppose I draw a distinction that not everyone will agree with.  EAPOL
frames are not RADIUS attributes in the classic sense of the definition.
I see tunneling EAP in RADIUS as a natural thing to do.  Many of the
other proposed new attributes seem like any other RADIUS attribute to
me, and thus I resist the notion of tunneling, or sub-typing.

>   If tagged attributes are sufficient, then I see no reason to add new
> sub-types.

That works for me.  Let's see if it works for others.

-- Dave

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

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Feb 2004 15:05:24 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft 
Date: Fri, 13 Feb 2004 10:07:43 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> The technical arguments that I have heard (and advanced) against
> sub-types are that it changes the RADIUS architecture (simple TLV
> structures), requires changes to the RADIUS dictionary, and breaks
> backwards compatibility with a large deployed base of RADIUS products.

  ... which we already know won't understand the new attributes.

  The only hard requirement I can see for backwards compatibility is
that old servers MUST be able to act as proxies for requests with new
attributes.  We've seen this behaviour with EAP-Message, so we know it
works.

> With SNMP, MIBs can be enrolled in SNMP management stations by a
> mechanical process because you can't re-define the ASN.1/BER data
> formats used in SNMP.  Should we settle for any less in RADIUS?

  No, but RADIUS does more.  The vast majority of use of SNMP is for
monitoring.  The SNMP servers don't *do* anything with the data they
manage.  That is, we generally don't expect to do an SNMP write in one
place, and then read back data elsewhere which is calculated by some
algorithm from the updates.  If that does happen, that data is usually
calculated by something outside of SNMP, like another application.

  RADIUS is an "active" protocol, in that it changes its responses
based on different inputs.  In contrast, SNMP is much more "passive".
This difference means that analogies to SNMP are less than perfect.

> However the sub-type attributes are not in any fundamental way different
> from "normal" RADIUS attributes.  So what are the reasons offered for
> treating them differently?  One reason seems to be "the convenience of
> grouping".  RADIUS already has a recognized method of grouping
> attributes.

  Using tunnel-type "tags" for grouping attributes is reasonable.

> A second reason seems to be "we will run out of attribute
> number space".  Let's take a head count of new attributes that fall
> within the scope of the charter before we deiced that, shall we?

  The rouch count posted to the list was what, 40-80 attributes?
That's at least approaching the boundary.

> While I do find the backwards compatibility reasons for NOT allowing
> sub-types to be compelling, I don't find the two reasons I have listed
> for allowing them to be compelling.

  If tagged attributes are sufficient, then I see no reason to add new
sub-types.

  Alan DeKok.

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

Delivery-date: Fri, 13 Feb 2004 13:48:47 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: new revision of the NAI RFC
Date: Fri, 13 Feb 2004 14:48:26 +0100

> > Wolfgang wrote:
> > nai         = username / ( username "@" realm ) / ( "@" realm" )
> [..]
> > NAIs are often transported in the User-Name attribute of RADIUS[10].
> 
> ..another example of a sub-attribute :-)

Dave wrote:
> Well, here's an even sillier "example"...

> Integer :== millions-part "," thousands-part "," hundreds-part ","
> units-part

> e.g. 1,000,000,000
> That makes integers sub-attributes, right?  :-)
In a way, yes. You are just using a positional syntax instead of TLV.
Your syntax has the same difficulties as sub-attributes. You can't
associate only a 'millions-part' with a user in the RADIUS database.
You have to specify the whole Integer. You are "tunneling" an
un-interpreted integer through RADIUS to some higher layer protocol
(eg. an accounting application).

Wolfgang

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

Delivery-date: Fri, 13 Feb 2004 13:25:46 +0000
content-class: urn:content-classes:message
Subject: RE: new revision of the NAI RFC
Date: Fri, 13 Feb 2004 08:25:16 -0500
From: "Nelson, David" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> > nai         =3D username / ( username "@" realm ) / ( "@" realm" )
> [..]
> > NAIs are often transported in the User-Name attribute of RADIUS[10].
>=20
> ..another example of a sub-attribute :-)

Well, here's an even sillier "example"...

Integer :=3D=3D millions-part "," thousands-part "," hundreds-part ","
units-part

e.g. 1,000,000,000

That makes integers sub-attributes, right?  :-)

-- Dave

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

Delivery-date: Fri, 13 Feb 2004 09:36:27 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: AW: new revision of the NAI RFC
Date: Fri, 13 Feb 2004 10:36:09 +0100

> nai         = username / ( username "@" realm ) / ( "@" realm" )
[..]
> NAIs are often transported in the User-Name attribute of RADIUS[10]. 

..another example of a sub-attribute :-)

Wolfgang

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

Delivery-date: Fri, 13 Feb 2004 09:16:48 +0000
Date: Fri, 13 Feb 2004 11:14:39 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: Pasi Eronen <[email-masked]>, Bernard Aboba <[email-masked]>
Subject: new revision of the NAI RFC

For your information: Pasi, Bernard, and myself published a new
draft, draft-arkko-roamops-rfc2486bis-00.txt which is an update
of the original NAI specification. It provides a few corrections,
clarifications, and support for a couple of new features such
as privacy and international character sets. It even touches
upon network selection feature discussed in EAP WG by talking
about the bang syntax.

Feedback appreciated. Do folks think a bis version makes sense?
Comments on content? Missed corrections? New functions make
sense?

Note that strictly speaking, there is no official home
at the IETF for this discussion, so if we generate lengthy
discussions based on this I'll promise to create a new list
for the purpose and not disturb the AAA, AAAEXT or EAP WGs.

Full list of modifications:

    o  International character set support has been added for both
       usernames and realms.

    o  Username privacy support has been added.

    o  A requirement to support NAI length of at least 253 octets has
       been added, and compatibility considerations among NAI lengths in
       this specification and various AAA protocols are discussed.

    o  The mediating network syntax and its implications have been fully
       described and not given only as an example.  Note that this syntax
       is not intended to be a full solution to network discovery and
       selection needs as defined in [draft-ietf-eap-netsel-problem].
       Rather, it is intended as a clarification of RFC 2486. It could
       also be used as a component in approaches such as [draft-adrangi].

    o  The realm BNF entry definition has been changed to avoid an error
       (infinite recursion) in the original specification.

    o  The x and special BNF entries have been clarified.

For more information, see the following URLs:

   http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt
   http://www.arkko.com/publications/nai/naibis.html

--Jari

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

Delivery-date: Fri, 13 Feb 2004 01:37:58 +0000
Date: Thu, 12 Feb 2004 17:49:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Korhonen Jouni <[email-masked]>
cc: [email-masked]
Subject: RE: Bof at next IETF?

> I would second that there is interest for the work done in RADIUSEXT.
> For example GSMA would most probably like to see several of these worked
> on drafts progress get eventually done. For
> example draft-adrangi-radius-extension-for-pwlan,
> draft-adrangi-radiusext-location-information and
> draft-adrangi-radius-chargeable-user-identity-attribute (which is worked
> on in background at the moment) are such to name few.

Has there been any official communication from the GSMA to the  IETF on
this subject?  We are trying to understand to what extend drafts under
consideration in RADEXT have ended up on the dependency list of
an SDO, including 3GPP, 3GPP2, or IEEE 802.

This is an important issue, since one of the principles of governing AAA
work in the IETF is that there needs to be a demonstrated need, as
evidenced by SDO dependencies, requirements documents authored by existing
IETF WGs, etc.

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

Delivery-date: Thu, 12 Feb 2004 20:50:35 +0000
content-class: urn:content-classes:message
Subject: FW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 15:49:53 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

<re-sending>

Wolfgang Beck writes...

> I could live without sub-attributes but I haven't heard a really
> convincing technical argument against them.

Well, I guess that begs the question of what constitutes "convincing"?
The technical arguments that I have heard (and advanced) against
sub-types are that it changes the RADIUS architecture (simple TLV
structures), requires changes to the RADIUS dictionary, and breaks
backwards compatibility with a large deployed base of RADIUS products.

I would offer an analogy.  Adding sub-types to RADIUS would be similar
to adding some sub-types (protocol-encoded information) as the data
value of an ASN.1 varbind in SNMP.  It is "tunneling" one protocol in
another.  In the case of SNMP, as in the case of RADIUS, we have a
simple and limited set of data types, and single level of TLV structure.
With SNMP, MIBs can be enrolled in SNMP management stations by a
mechanical process because you can't re-define the ASN.1/BER data
formats used in SNMP.  Should we settle for any less in RADIUS?

The one explicit case where we do tunnel a protocol in RADIUS is the
EAP-Message attribute.  If the information contained in the proposed
sub-types were as disparate from other RADIUS attributes as EAP frames
from RADIUS attributes, following this precedent would be reasonable.
However the sub-type attributes are not in any fundamental way different
from "normal" RADIUS attributes.  So what are the reasons offered for
treating them differently?  One reason seems to be "the convenience of
grouping".  RADIUS already has a recognized method of grouping
attributes.  A second reason seems to be "we will run out of attribute
number space".  Let's take a head count of new attributes that fall
within the scope of the charter before we deiced that, shall we?

While I do find the backwards compatibility reasons for NOT allowing
sub-types to be compelling, I don't find the two reasons I have listed
for allowing them to be compelling.

-- Dave

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

Delivery-date: Thu, 12 Feb 2004 12:59:14 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Thu, 12 Feb 2004 07:58:54 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Parviz Yegani" <[email-masked]>, <[email-masked]>

Avi Lior writes...
=20
> So this is great Dave.  So when is the BOF going to happen?

[DBN] I guess my point is that another BOF does not seem to be required.
What is required is active review of, and comment upon, the drafts on
the mailing list.  Those drafts that have been (or will be) revised to
fall within scope of the charter can progress.

After all, all official actions and decisions of the IETF are taken by
consensus of a WG on its mailing list, not by "hums" taken at meetings.

-- Dave

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

Delivery-date: Thu, 12 Feb 2004 12:26:52 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 13:26:27 +0100

Miguel,

you wrote:

> Wolfgang is proposing a third solution, let's call it "the hybrid solution". I said > it is hybrid because the SIP server calculates the MD5 of the entity-body, but the > Diameter (or Radius in your case) server authenticates the user. I wonder if the
> delegation of authentication to the SIP server would not solve your problem.
Correct me if have misunderstood your DIAMETER draft: authentication delegation
means, that the DIAMETER server knows a SIP server that knows how to
authenticate a user. This is sort of a routing function, that could be done
by a redirecting SIP proxy without using AAA protocol at all.

> I believe this hybrid solution would work also in the Diameter
> SIP application, we simply didn't have a requirement to
> implement it, so we didn't. 
As you are already supporting both scenarios, I see two solutions.

1. You define the SIP-Authentication-Context content as body-digest
instead of the whole SIP message body when using HTTP Digest and
qop=auth-int
2. You define an additional AVP eg. SIP-Authentication-Digest that
can be used for transportation of digest values. It contains the
body-digest and is only used in environments using RADIUS translators.

I'd prefer option 1, because it would make DIAMETER messages shorter
and would not introduce separate RADIUS-related variations for a single
function.

Wolfgang Beck

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

Delivery-date: Thu, 12 Feb 2004 12:25:10 +0000
Date: Thu, 12 Feb 2004 14:23:16 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft

[email-masked] wrote:
> At least I don't have a problem to add this hybrid scenario to the Diameter SIP application. However, I wouldn't be able to compromise on removing any of the existing two scenarions, since I am aware of interests in deployments that will use any of the other two.
> 
> Will that help? If so, I will add some text to the Diameter SIP application, some motivation, and will send to this WG for review (just the relevant paragraph).

I think this would be useful. Thanks!

--Jari

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

Delivery-date: Thu, 12 Feb 2004 12:08:25 +0000
Date: Thu, 12 Feb 2004 14:06:10 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft

I understand that there are different possible scenarios. But as you
can imagine (no matter what the minor protocol encoding differences
are) its hard to interoperate if the models underlying the
protocols are different. As I would not like to see market
fragmentation, is there something that you Wolfgang and Miguel
could do to move towards a similar model, or at least provide
an ability to support one common model?

--Jari

[email-masked] wrote:
>>>>My second significant comment at some point was the interoperation
>>>>with Diameter-based SIP AAA. I think this is a requirement. Can
>>>>you provide a section that explains how and under what limitations
>>>>this and draft-ietf-aaa-diameter-sip-app can work together?
>>>
>>>Sure. For example, draft-ietf-aaa-diameter-sip-app defines a
>>>SIP-Authentication-Context AVP which holds the SIP message body
>>>for qop=auth-int. draft-sterman-aaa-sip-01 saves space by 
>>
>>calculating
>>
>>>the body digest in the RADIUS client. As the maximum length 
>>
>>of RADIUS
>>
>>>messages is limited to 4096, I see no way around some kind 
>>
>>of compression.
>>
>>>DIAMETER allows much larger messages, but pre-computation 
>>
>>of the body
>>
>>>digest might be a good idea for this protocol, too.
>>
>>Ok. I'd prefer to see those considerations written down
>>somewhere. I believe that Miguel Garcia, who is working on
>>the Diameter SIp application, would be willing to listen
>>for feedback, if it turns out that interoperation is hard
>>for some specific reason.
>>
> 
> 
> Hi:
> 
> Wolfgang is correct in the sense that the Diameter SIP Application provides a SIP-Authentication-Context AVP which is intended to carry the whole entity-body in the case of SIP. 
> 
> I must warn you that the Diameter SIP application supports two authentication scenarios, one where the Diameter server is authenticating the user, in which case the SIP-Authentication-Contxt AVP may have significance. The other scenario we support takes place when the Diameter server delegates authentication to the SIP server (the Diameter client). In this case there is no need to transfer the entity-body accross the network. This is the solution that we offer in the Diameter SIP application.
> 
> Wolfgang is proposing a third solution, let's call it "the hybrid solution". I said it is hybrid because the SIP server calculates the MD5 of the entity-body, but the Diameter (or Radius in your case) server authenticates the user. I wonder if the delegation of authentication to the SIP server would not solve your problem.
> 
> I believe this hybrid solution would work also in the Diameter SIP application, we simply didn't have a requirement to implement it, so we didn't. 
> 
> My 0,02 EUR 
> 
> /Miguel
> 
> 

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

Delivery-date: Thu, 12 Feb 2004 10:33:33 +0000
Date: Thu, 12 Feb 2004 12:31:39 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: AW: AW: HTTP digest and RADIUS; new version of the Sterman draft

Beck01, Wolfgang wrote:
> 
> -----Ursprungliche Nachricht-----
> Von: Jari Arkko [mailto:[email-masked]]
> Gesendet: Donnerstag, 12. Februar 2004 09:29
> An: Beck, Wolfgang
> Cc: [email-masked]; [email-masked]
> Betreff: Re: AW: HTTP digest and RADIUS; new version of the Sterman
> draft
> 
> Jari Arkko wrote:
> 
>>>Beck01, Wolfgang wrote:
> 
> 
>>>Open issues: I hope that I have addressed all the issues that were
>>>raised in Minneapolis.
> 
> 
>>What about support for other algorithms than MD5? This was one
>>of my comments in Minneapolis. I took a new look at the draft.
>>It does not say anything about this, but on the other hand my
>>quick look did not reveal anything which would prevent them from
>>being supported. Can you say if you support them or not? Say, RFC
>>3310 support is included?
> 
> Other algorithms are supported as long as they don't define additional
> parameters. RfC 3310 defines a new 'auths' parameter, which would
> require an additional RADIUS (sub-)attribute. I am not sure if a
> general procedure can be valid for all possible algorithms.

Ah, I see. But I would think that any additional parameter could
be transported easily, as long as it fits the RFC 2617 section 2.1
syntax for "auth-param". Of course, this requires that the parameters
are indeed part of the HTTP authentication header, but this appears
to be the case in variations that I know of. Could you accommodate this
is in a general way? If not, perhaps you could add support for "auts"
from RFC 3310 specifically. But that does not appear to be necessary.

>>My second significant comment at some point was the interoperation
>>with Diameter-based SIP AAA. I think this is a requirement. Can
>>you provide a section that explains how and under what limitations
>>this and draft-ietf-aaa-diameter-sip-app can work together?
> 
> Sure. For example, draft-ietf-aaa-diameter-sip-app defines a
> SIP-Authentication-Context AVP which holds the SIP message body
> for qop=auth-int. draft-sterman-aaa-sip-01 saves space by calculating
> the body digest in the RADIUS client. As the maximum length of RADIUS
> messages is limited to 4096, I see no way around some kind of compression.
> DIAMETER allows much larger messages, but pre-computation of the body
> digest might be a good idea for this protocol, too.

Ok. I'd prefer to see those considerations written down
somewhere. I believe that Miguel Garcia, who is working on
the Diameter SIp application, would be willing to listen
for feedback, if it turns out that interoperation is hard
for some specific reason.

--Jari

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

Delivery-date: Thu, 12 Feb 2004 09:40:50 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: AW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 10:40:25 +0100

-----Ursprungliche Nachricht-----
Von: Jari Arkko [mailto:[email-masked]]
Gesendet: Donnerstag, 12. Februar 2004 09:29
An: Beck, Wolfgang
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: HTTP digest and RADIUS; new version of the Sterman
draft

Jari Arkko wrote:
>> Beck01, Wolfgang wrote:

>> Open issues: I hope that I have addressed all the issues that were
>> raised in Minneapolis.

> What about support for other algorithms than MD5? This was one
> of my comments in Minneapolis. I took a new look at the draft.
> It does not say anything about this, but on the other hand my
> quick look did not reveal anything which would prevent them from
> being supported. Can you say if you support them or not? Say, RFC
> 3310 support is included?
Other algorithms are supported as long as they don't define additional
parameters. RfC 3310 defines a new 'auths' parameter, which would
require an additional RADIUS (sub-)attribute. I am not sure if a
general procedure can be valid for all possible algorithms.

> My second significant comment at some point was the interoperation
> with Diameter-based SIP AAA. I think this is a requirement. Can
> you provide a section that explains how and under what limitations
> this and draft-ietf-aaa-diameter-sip-app can work together?
Sure. For example, draft-ietf-aaa-diameter-sip-app defines a
SIP-Authentication-Context AVP which holds the SIP message body
for qop=auth-int. draft-sterman-aaa-sip-01 saves space by calculating
the body digest in the RADIUS client. As the maximum length of RADIUS
messages is limited to 4096, I see no way around some kind of compression.
DIAMETER allows much larger messages, but pre-computation of the body
digest might be a good idea for this protocol, too.

Wolfgang

Thanks,

--Jari

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

Delivery-date: Thu, 12 Feb 2004 08:43:23 +0000
content-class: urn:content-classes:message
Subject: RE: AW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 10:42:52 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Jari,

> What about support for other algorithms than MD5? This was one
> of my comments in Minneapolis. I took a new look at the draft.
> It does not say anything about this, but on the other hand my
> quick look did not reveal anything which would prevent them from
> being supported. Can you say if you support them or not? Say, RFC
> 3310 support is included?

This would be nice to have.

> My second significant comment at some point was the interoperation
> with Diameter-based SIP AAA. I think this is a requirement. Can
> you provide a section that explains how and under what limitations
> this and draft-ietf-aaa-diameter-sip-app can work together?

That would be important to capture, in my opinion.

John

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

Delivery-date: Thu, 12 Feb 2004 08:31:19 +0000
Date: Thu, 12 Feb 2004 10:29:26 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: AW: HTTP digest and RADIUS; new version of the Sterman draft

Beck01, Wolfgang wrote:

> Open issues: I hope that I have addressed all the issues that were
> raised in Minneapolis.

What about support for other algorithms than MD5? This was one
of my comments in Minneapolis. I took a new look at the draft.
It does not say anything about this, but on the other hand my
quick look did not reveal anything which would prevent them from
being supported. Can you say if you support them or not? Say, RFC
3310 support is included?

My second significant comment at some point was the interoperation
with Diameter-based SIP AAA. I think this is a requirement. Can
you provide a section that explains how and under what limitations
this and draft-ietf-aaa-diameter-sip-app can work together?

Thanks,

--Jari

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

Delivery-date: Thu, 12 Feb 2004 08:19:20 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Thu, 12 Feb 2004 10:18:37 +0200
From: "Korhonen Jouni" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

I would second that there is interest for the work done in RADIUSEXT.
For example GSMA
would most probably like to see several of these worked on drafts
progress get eventually
done. Some of the next steps in global interoperator WLAN roaming
standardization work would
benefit (and is actually waiting for) on RADIUS extensions being drafted
in RADIUSEXT. For
example draft-adrangi-radius-extension-for-pwlan,
draft-adrangi-radiusext-location-information and
draft-adrangi-radius-chargeable-user-identity-attribute (which is worked
on in background
at the moment) are such to name few.

Best regards,
	Jouni

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

=20

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]=20
> Sent: 12. helmikuuta 2004 2:22
> To: 'Bernard Aboba'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Bof at next IETF?
>=20
> 80 People showed up and the vast majority expressed an=20
> interest in forming a
> WG.
>=20
> Work has progressed in the meanwhile.  There is plenty of=20
> evidence that
> there is interest.
>=20
> There are a number of new drafts, and there are a number of=20
> revised draft.
>=20
> Avi.
>=20
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]=20
> > Sent: Wednesday, February 11, 2004 4:22 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Bof at next IETF?
> >=20
> >=20
> > > I would have expected people to make more progress on some of the=20
> > > relevant drafts that were discussed in Minneapolis.  Having=20
> > a charter=20
> > > or WG shouldn't affect that work. I've been somewhat=20
> > suprised by the=20
> > > lack of progress.
> >=20
> > Having an IETF WG doesn't make work happen.  The IETF can=20
> > merely bring together people interested in doing work.  The=20
> > first test of whether a WG makes sense is whether the group,=20
> > when brought together, actually does work.
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> > [email-masked] with the word 'unsubscribe' in=20
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 12 Feb 2004 07:51:51 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 08:51:31 +0100

John Loughney wrote:
>> After re-checking the announcement list, I found that
>> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
>> is already available. It now has a Security Considerations section
>> and I've added support for Authentication-Info.

> Could you send a more detailed mail on what changes you have made,
> and what are the open issues which need further discussion?
Well, I have added some motivational paragraphs why HTTP digest support
for RADIUS is required in some environments. And when to choose DIAMETER
instead. There is a comparison of the SIP AAA options an operator has today.
I've added a step-by-step description of the RADIUS client and RADIUS
server behaviour. As the original draft was quite old, I had to update
most of the references and the authors' addresses.

To improve security, RADIUS clients that accept secured connections from
their SIP / HTTP clients are now required to have a secured connection to
the RADIUS server. RADIUS servers must return a Authentication-Info digest.

Open issues: I hope that I have addressed all the issues that were
raised in Minneapolis. There is the sub-attribute discussion, of course.
The draft needs official IANA assigned attribute types instead of the
experimental ones mentioned in -00. I could live without sub-attributes
but I haven't heard a really convincing technical argument against them.

Wolfgang Beck

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

Delivery-date: Thu, 12 Feb 2004 07:48:53 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Thu, 12 Feb 2004 09:48:31 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi,

> So how is *not* having a BOF going to help progress this further?

Well, that is something I don't have any control over.  However,=20
I guess people should have been asking about the bof a bit earlier ...

> > Revision of drafts well before the draft cut-off date is
> > a good indicator.
>=20
> Well, I can live with that but why hold us to a higher mark then say =
other
> WGs.

Well, I have the same problem as you.  Some WGs seem to be created =
without
much effort and others are heavily scrutinized.  My feelings is that =
there
should be some standard criteria here.
=20
> > Should it make a difference? What extra does a WG do to make=20
> > the work happen?
>=20
> In my opinion tons of difference.  For one it creates an open place =
where
> people can talk/comment about related topics.  But I guess some folks =
behave
> around here as if this is a closed community.

Well, we have the mailing list, so there is no closed community, imo.

> > My understanding was that progress on the drafts was expected=20
> > and discussion on the charter was to take place so that a=20
> > draft charter could be sent to the IESG.  We really haven't=20
> > discussed the charter. =20
>=20
> Regarding the Charter.  There were discussions. And a tone of =
discussion on
> subtypes and other related issues.

I didn't see a lot of text suggestions about how to improve the charter. =
 That
is more what I meant.

> >But at the last meeting, I remember=20
> > that a significant number of people thought it would be best=20
> > for the WG to be AAA Extensions, not just RADIUS extensions,=20
> > but we haven't discussed that on the mailing list.
>=20
> Not exactly my recollection at all.  First and foremost it was a =
RADIUS
> gathering.  We did agree to consider whether this should also be a =
Diameter
> extension group.  I wouldn't characterise it as a significant number =
of
> people.

I think more than 15 supported the idea, out of 80 is still a =
significant number
(1 or 2 would be insignificant). =20
=20
> But who cares.  Why should this minor point stall us?

I think we'd just need to update the charter accordingly, if this was =
OK.

John

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

Delivery-date: Thu, 12 Feb 2004 07:41:03 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: Bof at next IETF?
Date: Thu, 12 Feb 2004 02:40:55 -0500

John,
Thanx for the reply.  

First I will highlight this:
You said:
> And how do all of these related to the proposed charter and 
> what is the current support for including this work in the 
> WG?  These are the kind of discussions which are needed, imo.

So how is *not* having a BOF going to help progress this further?

Other comments are inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, February 12, 2004 2:41 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: Bof at next IETF?
> 
> 
> Hi Avi,
> 
> > John can you share with us what standard do you use to
> > measure progress.
> 
> Revision of drafts well before the draft cut-off date is
> a good indicator.

Well, I can live with that but why hold us to a higher mark then say other
WGs.

> > And can you please comment on how much work will be done if there 
> > wasn't a working group vs. how much work will be done if 
> there was a  
> > working group?
> 
> Should it make a difference? What extra does a WG do to make 
> the work happen?

In my opinion tons of difference.  For one it creates an open place where
people can talk/comment about related topics.  But I guess some folks behave
around here as if this is a closed community.
  
> > As well, in 58 8 to 10 people have agreed to do the majority of the 
> > work. Is this not enough?
> 
> My understanding was that progress on the drafts was expected 
> and discussion on the charter was to take place so that a 
> draft charter could be sent to the IESG.  We really haven't 
> discussed the charter.  

Regarding the Charter.  There were discussions. And a tone of discussion on
subtypes and other related issues.

>But at the last meeting, I remember 
> that a significant number of people thought it would be best 
> for the WG to be AAA Extensions, not just RADIUS extensions, 
> but we haven't discussed that on the mailing list.

Not exactly my recollection at all.  First and foremost it was a RADIUS
gathering.  We did agree to consider whether this should also be a Diameter
extension group.  I wouldn't characterise it as a significant number of
people.

But who cares.  Why should this minor point stall us?
 
> > Current partial listing(as obtained from the list)
> 

> John
> 

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

Delivery-date: Thu, 12 Feb 2004 07:15:23 +0000
content-class: urn:content-classes:message
Subject: RE: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 09:15:03 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Wolfgang,

> After re-checking the announcement list, I found that
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
> is already available. It now has a Security Considerations section
> and I've added support for Authentication-Info.

Could you send a more detailed mail on what changes you have made,
and what are the open issues which need further discussion?

thanks,
John

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

Delivery-date: Thu, 12 Feb 2004 07:10:49 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: HTTP digest and RADIUS; new version of the Sterman draft
Date: Thu, 12 Feb 2004 08:10:24 +0100

After re-checking the announcement list, I found that
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
is already available. It now has a Security Considerations section
and I've added support for Authentication-Info.

Wolfgang Beck

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

Delivery-date: Thu, 12 Feb 2004 05:41:16 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Thu, 12 Feb 2004 07:40:53 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi,

> John can you share with us what standard do you use to=20
> measure progress.

Revision of drafts well before the draft cut-off date is
a good indicator.
=20
> And can you please comment on how much work will be done if there =
wasn't a
> working group vs. how much work will be done if there was a  working =
group?

Should it make a difference? What extra does a WG do to make the work =
happen?
=20
> As well, in 58 8 to 10 people have agreed to do the majority of the =
work.
> Is this not enough?

My understanding was that progress on the drafts was expected and =
discussion
on the charter was to take place so that a draft charter could be sent =
to the
IESG.  We really haven't discussed the charter.  But at the last =
meeting,
I remember that a significant number of people thought it would be best
for the WG to be AAA Extensions, not just RADIUS extensions, but we =
haven't
discussed that on the mailing list.

> Current partial listing(as obtained from the list)

And how do all of these related to the proposed charter and what is the
current support for including this work in the WG?  These are the
kind of discussions which are needed, imo.

John

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

Delivery-date: Thu, 12 Feb 2004 01:16:23 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked], [email-masked], Avi Lior <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>
Subject: RE: Bof at next IETF?
Date: Wed, 11 Feb 2004 20:16:12 -0500

John can you share with us what standard do you use to measure progress.

And can you please comment on how much work will be done if there wasn't a
working group vs. how much work will be done if there was a working group?

As well, in 58 8 to 10 people have agreed to do the majority of the work.
Is this not enough?

FYI:

Current partial listing(as obtained from the list)

http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-pwlan
-00.txt
This will be updated by deadline

http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa
tion-00.txt
This is new work.

http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capabilit
y-00.txt
This is new work

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt
Updates previous one

http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0
1.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart-
01.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.txt

http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02.
txt
This will be updated.

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping-
00.txt
This will be updated

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi
on-00.txt
This is new work but outside scope of charter.

http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt
This is new work

>From IETF 58:

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping-
00.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart-
01.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-sspp-snmp-01.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02.
txt

http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounti
ng-00.txt

http://www.watersprings.org/pub/id/draft-sterman-aaa-sip-00.txt

http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

http://www.ietf.org/internet-drafts/draft-aboba-context-802-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roa
ming-01.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extensio
n-for-pwlan-00.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0
1.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-pe-discovery-04.tx
t

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2004 1:12 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Bof at next IETF?
> 
> 
> Hi Yegani,
> 
> > A number of drafts on Radius Extensions have been submitted
> for quite
> > sometime that need to be addressed in IETF soon. I'm not
> sure how this
> > could be done if the creation of the Radiusext WG is
> delayed further.
> > I thought we agreed at IETF58 in Minneapolis that RADIUSEXT was the
> > only home for these drafts, no?
> 
> I would have expected people to make more progress on some of
> the relevant 
> drafts that were discussed in Minneapolis.  Having a charter 
> or WG shouldn't affect that work. I've been somewhat suprised 
> by the lack of progress.
> 
> John
> 

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

Delivery-date: Thu, 12 Feb 2004 00:27:07 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Parviz Yegani <[email-masked]>, Avi Lior <[email-masked]>,  [email-masked]
Subject: RE: Bof at next IETF?
Date: Wed, 11 Feb 2004 19:27:03 -0500

Dave Nelson said:

>While there was substantial support for moving forward with 
> RADIUS Extensions, there was equally substantial support for 
> the limited scope of changes to RADIUS as presented in the 
> draft charter.  I think we are making progress toward meeting 
> but we have a ways to go yet.

So this is great Dave.  So when is the BOF going to happen?

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 12:28 AM
> To: Parviz Yegani; Avi Lior; [email-masked]
> Subject: RE: Bof at next IETF?
> 
> 
> Parviz Yegani writes...
>  
> > Given the strong support from the last IETF I thought 
> RADIUSEXT was on 
> > its way to become a new WG. What are we waiting for?
> 
> We are waiting for Internet Drafts, of suitable quality, that 
> fit within the proposed Charter, and volunteers to review 
> those drafts.
> 
> I have noticed a flurry of drafts coming out just prior to 
> the cutoff date for IEEE 59.  I would encourage all 
> interested parties to review these drafts, for protocol 
> quality, and also for compliance to the charter.  Please 
> review the drafts and submit commentary on this list.
> 
> While there was substantial support for moving forward with 
> RADIUS Extensions, there was equally substantial support for 
> the limited scope of changes to RADIUS as presented in the 
> draft charter.  I think we are making progress toward meeting 
> the requirement for suitable drafts, but we have a ways to go yet.
> 
> -- Dave
> 
> 

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

Delivery-date: Thu, 12 Feb 2004 00:22:28 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Bof at next IETF?
Date: Wed, 11 Feb 2004 19:22:11 -0500

80 People showed up and the vast majority expressed an interest in forming a
WG.

Work has progressed in the meanwhile.  There is plenty of evidence that
there is interest.

There are a number of new drafts, and there are a number of revised draft.

Avi.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 4:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Bof at next IETF?
> 
> 
> > I would have expected people to make more progress on some of the 
> > relevant drafts that were discussed in Minneapolis.  Having 
> a charter 
> > or WG shouldn't affect that work. I've been somewhat 
> suprised by the 
> > lack of progress.
> 
> Having an IETF WG doesn't make work happen.  The IETF can 
> merely bring together people interested in doing work.  The 
> first test of whether a WG makes sense is whether the group, 
> when brought together, actually does work.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Wed, 11 Feb 2004 17:42:22 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Wed, 11 Feb 2004 09:40:58 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I *totally* agree with John.  Since the last meeting, the group has
continued working on a number of drafts (that are within the scope of
the charter) based on the discussion/feedbacks on the mailing list.  So,
I don't understand why should not move forward with these drafts and
make progress. =20
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, February 10, 2004 11:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Bof at next IETF?
>=20
>=20
> > I would have expected people to make more progress on some of the=20
> > relevant drafts that were discussed in Minneapolis.  Having=20
> a charter=20
> > or WG shouldn't affect that work. I've been somewhat=20
> suprised by the=20
> > lack of progress.
>=20
> Having an IETF WG doesn't make work happen.  The IETF can=20
> merely bring together people interested in doing work.  The=20
> first test of whether a WG makes sense is whether the group,=20
> when brought together, actually does work.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 11 Feb 2004 09:41:42 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'John Schnizlein'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Wed, 11 Feb 2004 10:41:05 +0100

hi john, 

thanks for your summary. please see a small comment below:

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 8:49 PM
> To: Bernard Aboba
> Cc: Tschofenig Hannes; [email-masked]; [email-masked]
> Subject: Re: draft-jones-radius-geopriv
> 
> 
> Comments embedded in context:
> 
> At 02:06 PM 2/10/2004, Bernard Aboba wrote:
> 
> >I'm curious as to the contrast in approach taken by this draft 
> >versus the DHCP option.  Given the recent activity on encapsulation 
> >of RADIUS attributes in DHCP, isn't it important for the DHCP 
> >option and the RADIUS attribute to take similar approaches?
> 
> I would be surprised to see anyone determine the host's location
> through the RADIUS server, and pass that location through the 
> relay-agent sub-option to the DHCP server, in order for the DHCP 
> server to configure it at the host. However, similar approaches 
> to encoding the information would match the similar constraints
> that both DHCP and RADIUS are carried in a single UDP datagram.
> 
> >For example, if the goal is to make both the client and RADIUS 
> >server aware of their location, then the NAS might pass a location 
> >attribute to the RADIUS server, as well as passing this to the 
> >DHCP server in a relay option.  Encoding the information two very 
> >different ways seems like it results in unnecessary overhead.
> 
> A summary of the various intersections might be useful here:
> (for others - I know Bernard knows this background)
> 
> draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a 
> DHCP server to give a host the host's location, using (circuit-ID)
> information from the relay-agent and knowledge of the wiring plant.
> 
> draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP
> relay agent to relay RADIUS information to the DHCP server for its
> use in allocating configuration options.
> 
> draft-jones-radius-geopriv specifies a way for a NAS to tell a 
> RADIUS server the location of the NAS. The location of the NAS could
> be manually configured either in the NAS or in the RADIUS server
> with which it shares a secret. The radius-geopriv attribute might
> be added to the RADIUS attributes that are forwarded to a different
> (home) RADIUS server (in the global roaming situation).
> (If this summary is incorrect, please clarify.)

i guess there are two issues here: 

a) encoding of location information
b) who is authorized to distribute location information

for (a) the draft suggests to take a look at the results of the geopriv
working. initially i was a little bit skeptic about gmlv3 but when i looked
at the details i saw that these guys did good work. 
for (b) there are different scenarios. we tried to describe them in detail
to make an analysis easier. first, the visited network might distribute its
own location information to other networks - fairly simple stuff. second,
the visited network makes the location information of the end host
accessible. call me strange but i think that there are some privacy
considerations. 
once such infrastructure is deployed people tend to use it for other
applications as well. 

> 
> Before combining these ideas in a creative way, one would need to
> have a clear understanding of whose location information is needed
> where, and which provider of the information has the best 
> access to it.
certainly. 

> Since this analysis is already too difficult for some of us to want
> to attempt, making it worse with different information formats seems
> like over-kill.

ciao
hannes

> 
> John
> 

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

Delivery-date: Wed, 11 Feb 2004 09:30:10 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, John Schnizlein <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Wed, 11 Feb 2004 10:29:34 +0100

hi bernard, 

> > One concern, if this location configuration information (LCI)
> > is to be carried over RADIUS, is that the example in section 6
> > seems to be 993 characters long. This one attribute seems to be
> > taking a large share of the maximum RADIUS packet size of 4096.
> > [RFC 2865, p 15] Is there enough room for everything else that
> > would be expected with this attribute?
> 
> I'm curious as to the contrast in approach taken by this 
> draft versus the
> DHCP option.  Given the recent activity on encapsulation of RADIUS
> attributes in DHCP, isn't it important for the DHCP option 
> and the RADIUS
> attribute to take similar approaches?
> 
> For example, if the goal is to make both the client and RADIUS server
> aware of their location, then the NAS might pass a location 
> attribute to
> the RADIUS server, as well as passing this to the DHCP server 
> in a relay
> option.  Encoding the information two very different ways 
> seems like it
> results in unnecessary overhead.

that's certainly a good view. having many different ways of encoding things
is not the best approach. 

ciao
hannes

> 

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

Delivery-date: Wed, 11 Feb 2004 09:28:48 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'John Schnizlein'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: draft-jones-radius-geopriv
Date: Wed, 11 Feb 2004 10:28:15 +0100

hi john, 

you are fully right. we have also identified this as an issue. i think we
should also think about size considerations in the geopriv working group. 

ciao
hannes

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 7:12 PM
> To: Tschofenig Hannes
> Cc: [email-masked]; [email-masked]
> Subject: draft-jones-radius-geopriv
> 
> 
> Including the GeoPriv WG..
> 
> One concern, if this location configuration information (LCI) 
> is to be carried over RADIUS, is that the example in section 6 
> seems to be 993 characters long. This one attribute seems to be 
> taking a large share of the maximum RADIUS packet size of 4096.
> [RFC 2865, p 15] Is there enough room for everything else that
> would be expected with this attribute?
> 
> John
> 
> At 12:05 PM 2/10/2004, Hannes Tschofenig wrote:
> 
> >you can find the geogriv/radius draft at: 
> >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html
> >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt
> >
> >the draft tries awareness for privacy and reuses results of 
> the geopriv
> >working group. 
> 

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

Delivery-date: Wed, 11 Feb 2004 08:05:07 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: charter vs drafts, sub-types
Date: Wed, 11 Feb 2004 09:04:44 +0100

Dave Nelson wrote:

> I think that the "charter issue", as you call it, is that some of the
> proposed drafts fall outside the scope of the proposed charter, for
> which there is fairly broad support.
We had some discussion on the list about the sub-type issue.
I did not get the impression that we have rough consensus over
this part of the charter.

> The operative question is whether the charter should be revised or
> those particular drafts revised.  I am suggesting that the charter
> is fine and that the drafts that fall out of scope should be revised.
I chose to retain sub-attributes in my draft (which is still in
the queue of [email-masked]), as I felt the topic was still
undecided. And there are existing implementations that I did not want
to break without reason.

If the list decides, that 'thou shalt not use sub-attributes' I will
submit an updated version in a couple of days.

Wolfgang Beck

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

Delivery-date: Wed, 11 Feb 2004 07:10:16 +0000
Date: Tue, 10 Feb 2004 23:22:08 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: Bof at next IETF?

> I would have expected people to make more progress on some of the relevant
> drafts that were discussed in Minneapolis.  Having a charter or WG shouldn't
> affect that work. I've been somewhat suprised by the lack of progress.

Having an IETF WG doesn't make work happen.  The IETF can merely bring
together people interested in doing work.  The first test of whether a WG
makes sense is whether the group, when brought together, actually does
work.

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

Delivery-date: Wed, 11 Feb 2004 04:12:32 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Wed, 11 Feb 2004 06:12:01 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Yegani,

> A number of drafts on Radius Extensions have been submitted for quite =
sometime
> that need to be addressed in IETF soon. I'm not sure how this could be =
done if
> the creation of the Radiusext WG is delayed further. I thought we =
agreed at=20
> IETF58 in Minneapolis that RADIUSEXT was the only home for these =
drafts, no?

I would have expected people to make more progress on some of the =
relevant=20
drafts that were discussed in Minneapolis.  Having a charter or WG =
shouldn't
affect that work. I've been somewhat suprised by the lack of progress.

John

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

Delivery-date: Tue, 10 Feb 2004 22:28:37 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 17:28:34 -0500
From: "Nelson, David" <[email-masked]>
To: "Parviz Yegani" <[email-masked]>, <[email-masked]>

> Having a RADEXT BOF at IETF 59 would certainly help resolve the
charter
> issue. Is it too late to have a BOF at IETF next month in Seoul?

I think that the "charter issue", as you call it, is that some of the
proposed drafts fall outside the scope of the proposed charter, for
which there is fairly broad support.  The operative question is whether
the charter should be revised or those particular drafts revised.  I am
suggesting that the charter is fine and that the drafts that fall out of
scope should be revised.

Having another BOF will not make progress on reviewing and revising the
drafts.

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 22:23:30 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 17:23:16 -0500
From: "Nelson, David" <[email-masked]>
To: "Parviz Yegani" <[email-masked]>, <[email-masked]>

Parviz Yegani writes...

> A number of drafts on Radius Extensions have been submitted for quite
> sometime ...

Well, to be tongue-in-cheek, unlike fine wines, Internet Drafts do not
always improve with age. =20

Those drafts that call for extensions to RADIUS that are outside the
RADEXT proposed charter, and would break backwards compatibility with
the existing RADIUS RFCs and RADIUS implementations, should never, IMHO,
be published as Standards Track RFCs, and I have some serious doubts as
to whether they should be published as Informational RFCs.=20

The "need" for drafts to be acted upon quickly must be tempered by the
"need" for them to fall within the proposed charter and achieve broad
Internet Community consensus.

> I thought we agreed at IETF58 in Minneapolis that RADIUSEXT was the
> only home for these drafts, no?

We decided that drafts that fell within the scope of the proposed
charter would best find a home in an RADEXT WG.  There are other drafts
that might be handled in another (existing) IETF WG.  And there are some
drafts that require rework and revision to fit within the proposed
RADEXT WG charter.

So it depends on which subset of drafts you are referring to...

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 21:57:15 +0000
Date: Tue, 10 Feb 2004 13:56:57 -0800
To: "Nelson, David" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Bof at next IETF?

David,

Comments inline...

At 11:42 AM 2/10/2004 -0500, Nelson, David wrote:
>I have had some off-list discussions about the timing and progress of
>the nascent RADEXT WG, and have summarized my comments on this issue for
>the list, as I'm sure others have the same questions.
>
>While not have a RADEXT BOF at IETF 59 may be seen to create unfortunate
>timing, having a formal WG is not a prerequisite to doing work on the
>drafts.

At RADEXT BOF at IETF 58 we discussed this issue and there was substantial
support for creating a new WG, an attempt to find a home for the drafts on 
Radius
extensions. I'm a bit puzzled now that how your statement above "having a 
formal WG
is not a prerequisite to doing work on the drafts" would support what we 
discussed
and generally agreed at that meeting.

>Having volunteers to act as document editors, volunteers to do
>careful reviews, and a reflector list over which to communicate is all
>that is needed... for now.  Some of the submitted drafts, IMHO, are
>still out of scope for our charter.  I'd like to see more progress in
>that area before we formally ask the IESG to charter the WG.  Formally
>starting the WG, before the charter and scope issues are generally
>agreed upon will not, IMHO, accelerate the desired end product.

Having a RADEXT BOF at IETF 59 would certainly help resolve the charter
issue. Is it too late to have a BOF at IETF next month in Seoul?

Thanks,
Parviz

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

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

Delivery-date: Tue, 10 Feb 2004 21:31:29 +0000
Date: Tue, 10 Feb 2004 13:31:12 -0800
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Bof at next IETF?

Hello, John,

A number of drafts on Radius Extensions have been submitted for quite sometime
that need to be addressed in IETF soon. I'm not sure how this could be done if
the creation of the Radiusext WG is delayed further. I thought we agreed at 
IETF58
in Minneapolis that RADIUSEXT was the only home for these drafts, no?

Rgds,
Parviz

At 05:37 PM 2/10/2004 +0200, [email-masked] wrote:
>Hi Dan,
>
> > I was not aware about a call for volunteers. I am
> > volunteering to review the drafts. As they are individual
> > submissions at this point in time, I would be grateful to be
> > pointed to these drafts, as they are submitted and become available.
>
>It would be good if authors of individual documents would send email
>to this list, with pointers to their documents.  Also, it would
>help to have the authors give a short explaination of what they
>are trying to do, what things need discussion, etc.  I think the
>chairs & area directors are waiting for some discussion and interest
>level in this work.  The IETF generally doesn't have extra resources
>to do any work or reviews if there aren't people voluneering to do
>the work.
>
>br,
>John

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

Delivery-date: Tue, 10 Feb 2004 19:49:34 +0000
Date: Tue, 10 Feb 2004 14:49:10 -0500
To: Bernard Aboba <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: Re: draft-jones-radius-geopriv
Cc: Hannes Tschofenig <[email-masked]>, [email-masked], [email-masked]

Comments embedded in context:

At 02:06 PM 2/10/2004, Bernard Aboba wrote:

>I'm curious as to the contrast in approach taken by this draft 
>versus the DHCP option.  Given the recent activity on encapsulation 
>of RADIUS attributes in DHCP, isn't it important for the DHCP 
>option and the RADIUS attribute to take similar approaches?

I would be surprised to see anyone determine the host's location
through the RADIUS server, and pass that location through the 
relay-agent sub-option to the DHCP server, in order for the DHCP 
server to configure it at the host. However, similar approaches 
to encoding the information would match the similar constraints
that both DHCP and RADIUS are carried in a single UDP datagram.

>For example, if the goal is to make both the client and RADIUS 
>server aware of their location, then the NAS might pass a location 
>attribute to the RADIUS server, as well as passing this to the 
>DHCP server in a relay option.  Encoding the information two very 
>different ways seems like it results in unnecessary overhead.

A summary of the various intersections might be useful here:
(for others - I know Bernard knows this background)

draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a 
DHCP server to give a host the host's location, using (circuit-ID)
information from the relay-agent and knowledge of the wiring plant.

draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP
relay agent to relay RADIUS information to the DHCP server for its
use in allocating configuration options.

draft-jones-radius-geopriv specifies a way for a NAS to tell a 
RADIUS server the location of the NAS. The location of the NAS could
be manually configured either in the NAS or in the RADIUS server
with which it shares a secret. The radius-geopriv attribute might
be added to the RADIUS attributes that are forwarded to a different
(home) RADIUS server (in the global roaming situation).
(If this summary is incorrect, please clarify.)

Before combining these ideas in a creative way, one would need to
have a clear understanding of whose location information is needed
where, and which provider of the information has the best access to it.
Since this analysis is already too difficult for some of us to want
to attempt, making it worse with different information formats seems
like over-kill.

John

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

Delivery-date: Tue, 10 Feb 2004 19:16:31 +0000
Date: Tue, 10 Feb 2004 11:28:42 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: John Schnizlein <[email-masked]>
cc: Hannes Tschofenig <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-jones-radius-geopriv

> One concern, if this location configuration information (LCI)
> is to be carried over RADIUS, is that the example in section 6
> seems to be 993 characters long. This one attribute seems to be
> taking a large share of the maximum RADIUS packet size of 4096.
> [RFC 2865, p 15] Is there enough room for everything else that
> would be expected with this attribute?

Even if a RADIUS packet can be up to 4096 octets in length, it's still not
a good idea to cause fragmentation if it can be avoided.

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

Delivery-date: Tue, 10 Feb 2004 18:54:29 +0000
Date: Tue, 10 Feb 2004 11:06:13 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: John Schnizlein <[email-masked]>
cc: Hannes Tschofenig <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-jones-radius-geopriv

> One concern, if this location configuration information (LCI)
> is to be carried over RADIUS, is that the example in section 6
> seems to be 993 characters long. This one attribute seems to be
> taking a large share of the maximum RADIUS packet size of 4096.
> [RFC 2865, p 15] Is there enough room for everything else that
> would be expected with this attribute?

I'm curious as to the contrast in approach taken by this draft versus the
DHCP option.  Given the recent activity on encapsulation of RADIUS
attributes in DHCP, isn't it important for the DHCP option and the RADIUS
attribute to take similar approaches?

For example, if the goal is to make both the client and RADIUS server
aware of their location, then the NAS might pass a location attribute to
the RADIUS server, as well as passing this to the DHCP server in a relay
option.  Encoding the information two very different ways seems like it
results in unnecessary overhead.

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

Delivery-date: Tue, 10 Feb 2004 18:12:23 +0000
Date: Tue, 10 Feb 2004 13:12:11 -0500
To: "Hannes Tschofenig" <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: draft-jones-radius-geopriv
Cc: <[email-masked]>, [email-masked]

Including the GeoPriv WG..

One concern, if this location configuration information (LCI) 
is to be carried over RADIUS, is that the example in section 6 
seems to be 993 characters long. This one attribute seems to be 
taking a large share of the maximum RADIUS packet size of 4096.
[RFC 2865, p 15] Is there enough room for everything else that
would be expected with this attribute?

John

At 12:05 PM 2/10/2004, Hannes Tschofenig wrote:

>you can find the geogriv/radius draft at: 
>http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html
>http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt
>
>the draft tries awareness for privacy and reuses results of the geopriv
>working group. 

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

Delivery-date: Tue, 10 Feb 2004 17:30:33 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, <[email-masked]>
Subject: RE: [Partial] listing of RADIUS related Internet Drafts
Date: Tue, 10 Feb 2004 18:30:33 +0100

hi bernard, 

the geopriv-dhcp draft distributes its own location information as a
location generator. as such it is not directly related. it was written in
the early days of the geopriv working group. 

the draft is targeted at the geopriv working group. 

ciao
hannes

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Dienstag, 10. Februar 2004 18:31
> To: Tschofenig Hannes
> Cc: 'Nelson, David'; [email-masked]
> Subject: RE: [Partial] listing of RADIUS related Internet Drafts
> 
> 
> > you can find the geogriv/radius draft at: 
> > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html
> > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt
> >
> > the draft tries awareness for privacy and reuses results of the
> geopriv
> > working group.
> 
> Question:  How does this draft relate to the DHCP location 
> option, proposed below? Is this draft intended for the GEOPRIV WG?
> 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lci-option-0
3.txt

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

Delivery-date: Tue, 10 Feb 2004 17:18:40 +0000
Date: Tue, 10 Feb 2004 09:30:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
cc: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: [Partial] listing of RADIUS related Internet Drafts

> you can find the geogriv/radius draft at:
> http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html
> http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt
>
> the draft tries awareness for privacy and reuses results of the geopriv
> working group.

Question:  How does this draft relate to the DHCP location option,
proposed below? Is this draft intended for the GEOPRIV WG?

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lci-option-03.txt

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

Delivery-date: Tue, 10 Feb 2004 17:05:49 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, <[email-masked]>
Subject: RE: [Partial] listing of RADIUS related Internet Drafts
Date: Tue, 10 Feb 2004 18:05:32 +0100

hi nelson, 
hi all, 

you can find the geogriv/radius draft at: 
http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html
http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt

the draft tries awareness for privacy and reuses results of the geopriv
working group. 

ciao
hannes

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Dienstag, 10. Februar 2004 17:23
> To: [email-masked]
> Subject: [Partial] listing of RADIUS related Internet Drafts
> 
> 
> This list of RADIUS related Internet Drafts is taken from the 
> IETF Individual Submission ID web page.  Note that not all of 
> the IDs listed below are under active consideration for 
> RADEXT WG work at this time. Please add to this list as 
> appropriate.  Thanks.
> 
> 
> 
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten
sion-for-p
wlan-00.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-inf
ormation-00.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab
ility-00.txt

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt

http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-po
rt-01.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickst
art-01.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.t
xt

http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-02.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapp
ing-00.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-00.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

There is also a new draft on "GEOPRIV support for RADIUS" that has not been
posted to the IETF ID page yet. 

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

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

Delivery-date: Tue, 10 Feb 2004 16:49:15 +0000
Date: Tue, 10 Feb 2004 09:01:28 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: Bof at next IETF?

Thanks, John.  One of the pre-requisities for formation of an IETF WG is
the demonstration that a community of interest exists relating to the work
items included in the charter.  That means that we not only need
individual submissions fitting within the charter, but active discussion
on those items to demonstrate that there is interest in advancing them.

> It would be good if authors of individual documents would send email
> to this list, with pointers to their documents.  Also, it would
> help to have the authors give a short explaination of what they
> are trying to do, what things need discussion, etc.  I think the
> chairs & area directors are waiting for some discussion and interest
> level in this work.  The IETF generally doesn't have extra resources
> to do any work or reviews if there aren't people voluneering to do
> the work.

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

Delivery-date: Tue, 10 Feb 2004 16:42:24 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 11:42:08 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I have had some off-list discussions about the timing and progress of
the nascent RADEXT WG, and have summarized my comments on this issue for
the list, as I'm sure others have the same questions.

While not have a RADEXT BOF at IETF 59 may be seen to create unfortunate
timing, having a formal WG is not a prerequisite to doing work on the
drafts.  Having volunteers to act as document editors, volunteers to do
careful reviews, and a reflector list over which to communicate is all
that is needed... for now.  Some of the submitted drafts, IMHO, are
still out of scope for our charter.  I'd like to see more progress in
that area before we formally ask the IESG to charter the WG.  Formally
starting the WG, before the charter and scope issues are generally
agreed upon will not, IMHO, accelerate the desired end product.

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 16:23:41 +0000
content-class: urn:content-classes:message
Subject: [Partial] listing of RADIUS related Internet Drafts
Date: Tue, 10 Feb 2004 11:22:47 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This list of RADIUS related Internet Drafts is taken from the IETF
Individual Submission ID web page.  Note that not all of the IDs listed
below are under active consideration for RADEXT WG work at this time.
Please add to this list as appropriate.  Thanks.

http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p
wlan-00.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-inf
ormation-00.txt

http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab
ility-00.txt

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt

http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt

http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-po
rt-01.txt

http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickst
art-01.txt

http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.t
xt

http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-02.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapp
ing-00.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-00.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

There is also a new draft on "GEOPRIV support for RADIUS" that has not
been posted to the IETF ID page yet.=20

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

Delivery-date: Tue, 10 Feb 2004 15:37:43 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 17:37:28 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Dan,

> I was not aware about a call for volunteers. I am=20
> volunteering to review the drafts. As they are individual=20
> submissions at this point in time, I would be grateful to be=20
> pointed to these drafts, as they are submitted and become available.

It would be good if authors of individual documents would send email
to this list, with pointers to their documents.  Also, it would
help to have the authors give a short explaination of what they
are trying to do, what things need discussion, etc.  I think the
chairs & area directors are waiting for some discussion and interest
level in this work.  The IETF generally doesn't have extra resources
to do any work or reviews if there aren't people voluneering to do
the work.

br,
John

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

Delivery-date: Tue, 10 Feb 2004 15:35:20 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 10:35:02 -0500
From: "Nelson, David" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>

> I was not aware about a call for volunteers. I am volunteering to
review
> the drafts. As they are individual submissions at this point in time,
I
> would be grateful to be pointed to these drafts, as they are submitted
and
> become available.

Dan,

I'll review the list of those that I am aware of, and post a pointer on
this reflector to any that haven't been announced here.

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 15:33:31 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 10:32:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dan Romascanu writes...
=20
> Why?

Please see my reply to Parviz's message.  If that explanation is not
sufficient, please reply, and I'll attempt to elaborate.  Thanks.

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 15:33:10 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 17:32:33 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Parviz Yegani" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>

I was not aware about a call for volunteers. I am volunteering to review =
the drafts. As they are individual submissions at this point in time, I =
would be grateful to be pointed to these drafts, as they are submitted =
and become available.

Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Nelson, David
> Sent: 10 February, 2004 5:28 PM
> To: Parviz Yegani; Avi Lior; [email-masked]
> Subject: RE: Bof at next IETF?
>=20
>=20
> Parviz Yegani writes...
> =20
> > Given the strong support from the last IETF I thought=20
> RADIUSEXT was on
> > its way to become a new WG. What are we waiting for?
>=20
> We are waiting for Internet Drafts, of suitable quality, that=20
> fit within
> the proposed Charter, and volunteers to review those drafts.
>=20
> I have noticed a flurry of drafts coming out just prior to the cutoff
> date for IEEE 59.  I would encourage all interested parties to review
> these drafts, for protocol quality, and also for compliance to the
> charter.  Please review the drafts and submit commentary on this list.
>=20
> While there was substantial support for moving forward with RADIUS
> Extensions, there was equally substantial support for the=20
> limited scope
> of changes to RADIUS as presented in the draft charter.  I=20
> think we are
> making progress toward meeting the requirement for suitable=20
> drafts, but
> we have a ways to go yet.
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 10 Feb 2004 15:28:29 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 10:28:13 -0500
From: "Nelson, David" <[email-masked]>
To: "Parviz Yegani" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>

Parviz Yegani writes...
=20
> Given the strong support from the last IETF I thought RADIUSEXT was on
> its way to become a new WG. What are we waiting for?

We are waiting for Internet Drafts, of suitable quality, that fit within
the proposed Charter, and volunteers to review those drafts.

I have noticed a flurry of drafts coming out just prior to the cutoff
date for IEEE 59.  I would encourage all interested parties to review
these drafts, for protocol quality, and also for compliance to the
charter.  Please review the drafts and submit commentary on this list.

While there was substantial support for moving forward with RADIUS
Extensions, there was equally substantial support for the limited scope
of changes to RADIUS as presented in the draft charter.  I think we are
making progress toward meeting the requirement for suitable drafts, but
we have a ways to go yet.

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 15:27:32 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 17:27:16 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>

Why?

Regards,

Dan

> Avi Lior writes...
>=20
> > Is there going to be a BOF at the IETF 59.
>=20
> No.
> =20
> > Also did we post minutes from the last BOF.
>=20
> Yes.  Here's the link: http://www.ietf.org/proceedings/03nov/177.htm
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 10 Feb 2004 15:23:24 +0000
content-class: urn:content-classes:message
Subject: RE: Bof at next IETF?
Date: Tue, 10 Feb 2004 10:22:44 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Is there going to be a BOF at the IETF 59.

No.
=20
> Also did we post minutes from the last BOF.

Yes.  Here's the link: http://www.ietf.org/proceedings/03nov/177.htm

-- Dave

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

Delivery-date: Tue, 10 Feb 2004 08:11:36 +0000
Date: Tue, 10 Feb 2004 00:10:56 -0800
To: Avi Lior <[email-masked]>, [email-masked]
From: Parviz Yegani <[email-masked]>
Subject: Re: Bof at next IETF?

Given the strong support from the last IETF I thought RADIUSEXT was on
its way to become a new WG. What are we waiting for?

-Parviz

At 02:48 AM 2/10/2004 -0500, Avi Lior wrote:
>Is there going to be a BOF at the IETF 59.  If so when so we can plan our
>travels.
>
>Also did we post minutes from the last BOF.
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 10 Feb 2004 07:48:40 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Bof at next IETF?
Date: Tue, 10 Feb 2004 02:48:15 -0500

Is there going to be a BOF at the IETF 59.  If so when so we can plan our
travels.

Also did we post minutes from the last BOF.

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

Delivery-date: Mon, 09 Feb 2004 15:28:59 +0000
content-class: urn:content-classes:message
Subject: RE: Subtypes (again) and other ideas
Date: Mon, 9 Feb 2004 10:28:32 -0500
From: "Nelson, David" <[email-masked]>
To: "Victor Gamov" <[email-masked]>, <[email-masked]>

Victor Gamov writes...

> I red this pecifications and now I have new ideas about our problem.
>=20
> 1. I think that we need to use VSA with Vendor-Id=3D0 (standard =
RADIUS)
to
> extend standard RADIUS attributes space.  It's very possible that
> current attribute space will be exceed in future.

DBN: I don't think there is any credible evidence that the Standard
RADIUS attribute space, for attributes that would pass "IETF standards
action" review, will be exhausted anytime in the near future.  If, in
fact, that does come to pass during the lifetime of RADIUS, then it
should be addressed at that point in time.  At this juncture, it is mere
speculation.

> 2. New attribute type from still unassigned attribute space with
> following format to extend Service-specific attributes:

DBN: "Service-Specific" as opposed to "Vendor-Specific"?  What
distinguishes a Service-Specific attribute from a RADIUS Standards Track
attribute?
=20
> 3. When different applications need to share some attribute we can add
> it in RADIUS VSA (with Vendor-ID 0) attribute space after some
> discussions.  So item 1 is very useful for this.

DBN: When multiple applications have a shared need for a RADIUS
attribute, it belongs in the Standards Track attribute number space.

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

Delivery-date: Mon, 09 Feb 2004 12:51:32 +0000
Date: Mon, 09 Feb 2004 15:50:41 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
CC: Avi Lior <[email-masked]>, "'Nakhjiri Madjid-MNAKHJI1'" <[email-masked]>
Subject: Re: Subtypes (again) and other ideas

Avi Lior wrote:
> 
>>-----Original Message-----
>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>>Sent: Tuesday, January 27, 2004 3:32 PM
>>To: 'Avi Lior'; 'Victor Gamov'; [email-masked]
>>Subject: RE: Subtypes (again) and other ideas
>>
>>
>>Hi Avi,
>>
>>I am not sure, if I understand the problem you are raising 
>>below. Are you saying that a sub attribute out of for 
>>instance WLAN attribute (which is treated as a vendor 
>>specific) needs security, then that piece of data cannot be a 
>>subattribute anymore? If true, although I agree that is a 
>>problem, but isn't that already a 
>>problem for vendor specific attributes?
> 
> 
> It is. 

Hi gentlemen!

I'm really sorry, that I was absent for a long time

>>The suggested idea seems to be the best way to handle all the 
>>new applications that are popping up with the limited 
>>attribute space. Furthermore, this approach won't tie the 
>>hand of application designers to have to map all their data 
>>into existing attributes.
> 
> But don't forget my other reason. Not using application space allows us to
> reuse attributes.
> 
> I think that there is a better approach to handling the limited attribute
> space for RADIUS.  I already posted an internet draft for that.  See
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lior-radius-attribut
> e-type-extension-00.txt 

I red this pecifications and now I have new ideas about our problem.

1. I think that we need to use VSA with Vendor-Id=0 (standard RADIUS) to 
extend standard RADIUS attributes space.  It's very possible that 
current attribute space will be exceed in future.

2. New attribute type from still unassigned attribute space with 
following format to extend Service-specific attributes:

  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 (241)  |    Length     |        Service-Type           |
+---------------+---------------+-------------------------------+
|    Service-Type (cont)        |  String...
+---------------+---------------+---------------+---------------+

Type 241 for Service-Specific

Length >= 7

Service-Type = value of Service-Type attribute.
(We need to propose new Service-Type values for different services 
(Wi-Fi, LAN, PPPoE etc))

String may be in following format:

+---------------+---------------+---------------+---------------+
|          Extended-Type        |       ID      |Extended-Length|
+---------------+---------------+---------------+---------------+
|   Extended-Value...
+---------------+---------------+---------------+---------------+

Extended-Type -- type of service-specific attribute

ID -- random value from 0 to 255 to identify different service-specific 
attributes with equal Extended-Type in one packet

Extended-Length >= 5

Extended-Value -- Service-Type and Extended-Type specific value

Attributes with equal Service-Type, Extended-Type and ID MUST be 
concatenated. This allows Extended-Value longer than 245 bytes

3. When different applications need to share some attribute we can add 
it in RADIUS VSA (with Vendor-ID 0) attribute space after some 
discussions.  So item 1 is very useful for this.

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