Subject: RE: Usage model and scenarios

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Tue, 29 Sep 2009 18:01:24 +0200

If we restrict ourselves to the SP deployment "uplink-IPv6-address"
seems then the right term as already proposed. Letting aside the
loopback numbering problem.

I had in mind to extend a bit the field of applications and account for
Enterprise deployment on LAN where "uplink" is not a familiar term.

Benoit

-----Original Message-----
From: Mark Townsley (townsley) 
Sent: Tuesday, September 29, 2009 5:35 PM
To: 'Maglione Roberta'; 'Bernard Aboba'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; 'David B. Nelson'; [email-masked]'; Benoit
Lourdelet (blourdel)
Subject: RE: Usage model and scenarios

I can imagine the desire to have an ipv6 address on the wan link itself,
as well as one not associated with the physical interface, but a
"loopback" on the RG. If this is the former, I think it should be
labeled as such. Whether we need the latter is perhaps another
discussion. (in ipv4 of course we didn't have these luxuries of
assigning addresses to everything that might be addressable. Doesn't
mean ipv6 will evolve in the same manner.)

Sent from my mobile.

--
to unsubscribe send 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, 29 Sep 2009 16:02:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Usage model and scenarios
Date: Tue, 29 Sep 2009 18:01:24 +0200
From: "Benoit Lourdelet (blourdel)" <[email-masked]>
To: "Mark Townsley (townsley)" <[email-masked]>, "Maglione Roberta" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "David B. Nelson" <[email-masked]>, <[email-masked]>

If we restrict ourselves to the SP deployment "uplink-IPv6-address"
seems then the right term as already proposed. Letting aside the
loopback numbering problem.

I had in mind to extend a bit the field of applications and account for
Enterprise deployment on LAN where "uplink" is not a familiar term.

Benoit

-----Original Message-----
From: Mark Townsley (townsley) 
Sent: Tuesday, September 29, 2009 5:35 PM
To: 'Maglione Roberta'; 'Bernard Aboba'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; 'David B. Nelson'; [email-masked]'; Benoit
Lourdelet (blourdel)
Subject: RE: Usage model and scenarios

I can imagine the desire to have an ipv6 address on the wan link itself,
as well as one not associated with the physical interface, but a
"loopback" on the RG. If this is the former, I think it should be
labeled as such. Whether we need the latter is perhaps another
discussion. (in ipv4 of course we didn't have these luxuries of
assigning addresses to everything that might be addressable. Doesn't
mean ipv6 will evolve in the same manner.)

Sent from my mobile.

--
to unsubscribe send 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, 29 Sep 2009 14:46:43 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IPv6 support: potential approaches
Date: Tue, 29 Sep 2009 07:41:57 -0700

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

During the discussion of the tagging scheme proposed in draft-lourdelet, 
the topic of new data types has come up. 

This seems to be one of those situations where it would seem that we
are faced with choosing the lesser of 2 (or maybe 3) evils:

1. Creating a new tagging scheme, along with several new attributes; 
2. Creating a complex (or opaque?) attribute to encapsulate all the items that could
potentially be sent in a router advertisement; 
3. Creating a dependency on a generic, but not yet completed tagging
scheme (Extended Attributes). 

Each of these choices requires new code on both the RADIUS client and server,
so that this would not appear to be a consideration. 

In comparing choices number 1 and 3,  the third choice seems preferable in that
it would amortize the pain of supporting new data types over a wider range of
uses. 

However, it is not clear to me that either choices 1 or 3 are superior to choice 2
in terms of total effort required, particularly if the route advertisement attribute
could be engineered as an opaque (string) attribute.  This would remove the need
to add code on the RADIUS server. 

Am I missing any potential choices or are the choices simpler than those provided
above? 

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
During the discussion of the tagging scheme proposed in draft-lourdelet, <br>the topic of new data types has come up. <br><br>This seems to be one of those situations where it would seem that we<br>are faced with choosing the lesser of 2 (or maybe 3) evils:<br><br>1. Creating a new tagging scheme, along with several new attributes; <br>2. Creating a complex (or opaque?) attribute to encapsulate all the items that could<br>potentially be sent in a router advertisement; <br>3. Creating a dependency on a generic, but not yet completed tagging<br>scheme (Extended Attributes). <br><br>Each of these choices requires new code on both the RADIUS client and server,<br>so that this would not appear to be a consideration. <br><br>In comparing choices number 1 and 3,&nbsp; the third choice seems preferable in that<br>it would amortize the pain of supporting new data types over a wider range of<br>uses. <br><br>However, it is not clear to me that either choices 1 or 3 are superior to choice 2<br>in terms of total effort required, particularly if the route advertisement attribute<br>could be engineered as an opaque (string) attribute.&nbsp; This would remove the need<br>to add code on the RADIUS server. <br><br>Am I missing any potential choices or are the choices simpler than those provided<br>above? <br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_841f9965-2847-440a-8666-ccc5cf86a392_--

--
to unsubscribe send 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, 29 Sep 2009 14:28:39 +0000
From: Bernard Aboba <[email-masked]>
To: Mark Townsley <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, "David B. Nelson" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Usage model and scenarios
Date: Tue, 29 Sep 2009 07:28:08 -0700

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mark Townsley wrote:

"Is this a wan interface IPv6 address, or a lan-side delegated prefix?
And, might we want both? Even a third that might be the management IPv6
address assigned to a loopback?

If the scope is far less here, that's fine with me, but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of the issues that has confused members of the WG who have attempted to review the document. Overall, the  usage model underlying the document is unclear and this could potentially result in interoperability problems. 

For example, are we talking about prefix delegation, then presumably we are looking to utilize the attributes defined in RFC 4818. 

If we are not talking about prefix delegation, then are we utilizing the address assignment model of PPP IPv6CP or DHCPv6?  If it is IPv6CP, then it would not seem to make sense for the IPv6-Address in question to be that of the client interface, since that is already determined by the attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id).  

If we are utilizing the address assignment model of DHCPv6, then is the NAS acting as a DHCPv6 server?  Since RADIUS is spoken between a NAS and a RADIUS server, if the DHCPv6 server does not reside on the NAS, then this raises questions about what entities are involved in the RADIUS protocol conversation, and whether authentication (or a Call Check) is taking place. 

Outlining the specific scenarios that under consideration and the requirements for a solution would help greatly in promoting progress on this document. 
 		 	   		  
--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mark Townsley wrote:<br><br>"Is this a wan interface IPv6 address, or a lan-side delegated prefix?
And, might we want both? Even a third that might be the management IPv6
address assigned to a loopback?<br>
<br>
If the scope is far less here, that's fine with me, but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."<br><br>I think this is one of the issues that has confused members of the WG who have attempted to review the document. Overall, the&nbsp; usage model underlying the document is unclear and this could potentially result in interoperability problems. <br><br>For example, are we talking about prefix delegation, then presumably we are looking to utilize the attributes defined in RFC 4818. <br><br>If we are not talking about prefix delegation, then are we utilizing the address assignment model of PPP IPv6CP or DHCPv6?&nbsp; If it is IPv6CP, then it would not seem to make sense for the IPv6-Address in question to be that of the client interface, since that is already determined by the attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id).&nbsp; <br><br>If we are utilizing the address assignment model of DHCPv6, then is the NAS acting as a DHCPv6 server?&nbsp; Since RADIUS is spoken between a NAS and a RADIUS server, if the DHCPv6 server does not reside on the NAS, then this raises questions about what entities are involved in the RADIUS protocol conversation, and whether authentication (or a Call Check) is taking place. <br><br>Outlining the specific scenarios that under consideration and the requirements for a solution would help greatly in promoting progress on this document. <br> 		 	   		  </body>
</html>
--_4c741b3f-8be6-465d-bccd-1c78bbaee459_--

--
to unsubscribe send 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, 29 Sep 2009 13:57:20 +0000
Date: Tue, 29 Sep 2009 15:56:00 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked],  "'David B. Nelson'" <[email-masked]>, [email-masked], 'Mark Townsley' <[email-masked]>
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Alan DeKok [[email-masked]] writes:
>>...  Having an attribute named just
>> "IPv6-Address" will be confusing.
> 
> Or useful; maybe they're the same thing?

  Sure, if we presume that RADIUS only ever transports one IPv6-address
attribute.  Why not call it IPv6-Address?

> Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
> single octet.

  Fine by me.

...
> Again, a single octet should suffice, no?

  Fine by me.

  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: Mon, 28 Sep 2009 15:07:19 +0000
Date: Mon, 28 Sep 2009 08:04:51 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
Reply-To: Behcet Sarikaya <[email-masked]>
Subject: Re: IPv6 Address Option
To: Bernard Aboba <[email-masked]>, [email-masked], [email-masked], "[email-masked]" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: [email-masked], Mark Townsley <[email-masked]>

--0-226991051-1254150291=:30207
Content-Type: text/plain; charset=us-ascii

Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet

>
>From: Bernard Aboba <[email-masked]>
>To: [email-masked]; [email-masked]; "[email-masked]" <[email-masked]>; David B. Nelson <[email-masked]>
>Cc: [email-masked]; Mark Townsley <[email-masked]>
>Sent: Sunday, September 27, 2009 3:18:16 PM
>Subject: RE: IPv6 Address Option
>
> >
>> No. Several people replied. They just supported the call without any comments, but they promised to comment.
>
>In looking at the archive, these are the only people whose response indicated support of the document: 
>
>Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
>Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
>Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html
>
>Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 
>
>>Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).
>
>The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  
>
>The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 
>
>And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 
>
>
>
>
>
>
>
>

--0-226991051-1254150291=:30207
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Hi Bernard,<br>&nbsp; There is also this:<br><br><span><a target="_blank" href="https://ops.ietf.org/lists/radiusext/2009/msg00371.html">https://ops.ietf.org/lists/radiusext/2009/msg00371.html</a></span><br><br>Regards,<br><br>Behcet<br></div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font face="Tahoma" size="2"><b><span style="font-weight: bold;">From:</span></b> Bernard Aboba &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> [email-masked]; [email-masked]; "[email-masked]" &lt;[email-masked]&gt;;
 David B. Nelson &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> [email-masked]; Mark Townsley &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Sunday, September 27, 2009 3:18:16 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: IPv6 Address Option<br></font><br>

<style><!--
.hmmessage P
{
margin:0px;padding:0px;}
body.hmmessage
{
font-size:10pt;font-family:Verdana;}
--></style>

<br>&gt; No. Several people replied. They just supported the call without any comments, but they promised to comment.<br><br>In looking at the archive, these are the only people whose response indicated support of the document: <br><br><span>Glen Zorn (author): <a target="_blank" href="http://ops.ietf.org/lists/radiusext/2009/msg00276.html">http://ops.ietf.org/lists/radiusext/2009/msg00276.html</a></span><br><span>Miles David: <a target="_blank" href="http://ops.ietf.org/lists/radiusext/2009/msg00349.html">http://ops.ietf.org/lists/radiusext/2009/msg00349.html</a></span><br><span>Yungui Wang: <a target="_blank" href="http://ops.ietf.org/lists/radiusext/2009/msg00354.html">http://ops.ietf.org/lists/radiusext/2009/msg00354.html</a></span><br><br>Aside from these individuals, who else has indicated support for the document?&nbsp; Please provide links to their emails. <br><br>&gt;Well, we certainly would be happy to have David on board. However, I think the
 document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).<br><br>The issue isn't how many editors the document has.&nbsp; The issue is the pace at which the document has evolved in response to feedback.&nbsp; <br><br>The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.&nbsp; If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.&nbsp; Providing deadlines without engaged people doesn't help. <br><br>And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. <br><br><br><br><br><br><br><br> 		 	   		  </div></div></blockquote></div><br>

      </body></html>
--0-226991051-1254150291=:30207--

--
to unsubscribe send 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, 28 Sep 2009 10:08:26 +0000
Date: Mon, 28 Sep 2009 11:30:58 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Alan DeKok [mailto:[email-masked]] writes:
>>   You haven't pointed out which portions of the design guidelines
>> document violate that section.  You have had multiple opportunities to
>> do so.
> 
> See attachment.

  I don't count "virtually all of the document is wrong" as a useful
comment.  It doesn't propose anything that can be done to the document
to correct the alleged flaws.

  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: Mon, 28 Sep 2009 08:48:54 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 15:47:08 +0700

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:[email-masked]] writes:
> > Speaking of which, perhaps you would like to address section 6 of RFC
> 2119.
> 
>   You haven't pointed out which portions of the design guidelines
> document violate that section.  You have had multiple opportunities to
> do so.

See attachment.

> 
>   I don't see why I should address non-existent issues.
> 
>   Alan DeKok.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

From: "Glen Zorn" <[email-masked]>
Sender: <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>,
	<[email-masked]>,
	<[email-masked]>,
	<[email-masked]>,
	<[email-masked]>,
	<[email-masked]>,
	<[email-masked]>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:[email-masked]]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.

------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/html;
	boundary="----=_NextPart_000_00E8_01CA4015.C161E670";
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

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

<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>

<div>

<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#00B050'>Bernard Aboba [mailto:[email-masked]] &nbsp;writes:<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Arial Black","sans-serif";color:#1F497D'>WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems relevant:</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>6.
Guidance in the use of these Imperatives</span><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
Imperatives of the type defined in this memo must be used with care</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
and sparingly.&nbsp; In particular, they MUST only be used where it is</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
actually required for interoperation or to limit behavior which has</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
potential for causing harm (e.g., limiting retransmisssions)&nbsp; For</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
example, they must not be used to try to impose a particular method</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
on implementors where the method is not required for</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
interoperability.</span><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>[BA]
Are there specific uses of normative language in the document that you believe
are inappropriate? &nbsp; <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#00B050'>With the caveat that it&#8217;s been some time since I read the
draft, based upon my last review I&#8217;d have to say virtually all the uses
of RFC 2119 requirements language in the document are problematic.&nbsp; I plan
to go through the note in depth again this week.&nbsp; There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, easily
ignored (they are &#8220;guidelines&#8221;, after all).&nbsp; However, &nbsp;at
some point during the final discussions before the publication of RFC 5580 I realized
that the document, far from being a set of harmless suggestions on style, was in
fact a club to be used by pompous asses to keep people from getting real work
done.&nbsp; If you recall, my major arguments against the attributes defined in
5580 were based upon non-compliance w/the Design Guidelines document (yes, that
would make me one of those pompous asses &amp; I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and the
IESG for my misguided behavior).&nbsp; In fact, though, there was nothing
technically wrong with the geopriv attributes: they would have worked just
fine, thank you.&nbsp; Their only sin was deviation from a set of rules based
upon a highly suspect historical characterization of RADIUS development and a
simplistic (if not downright primitive processing model).&nbsp; At any rate,
removing the RFC 2119 language from the draft would go a long way toward making
the document truly harmless.<o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_001E_01CA4052.F92D1E20--

------=_NextPart_000_0023_01CA4052.F92D6C40--

--
to unsubscribe send 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, 28 Sep 2009 07:39:18 +0000
Date: Mon, 28 Sep 2009 09:38:38 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Alan DeKok [mailto:[email-masked]] writes:
> Speaking of which, perhaps you would like to address section 6 of RFC 2119.

  You haven't pointed out which portions of the design guidelines
document violate that section.  You have had multiple opportunities to
do so.

  I don't see why I should address non-existent issues.

  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: Mon, 28 Sep 2009 07:21:31 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'MILES DAVID'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'David B. Nelson'" <[email-masked]>, <[email-masked]>, "'Mark Townsley'" <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:00 +0700

Alan DeKok [[email-masked]] writes:

> MILES DAVID wrote:
> >> Uplink-IPv6-Address instead of IPv6-Address
> > 	I know the supporting text says "is assigned to the uplink of
> > the user equipment" but uplink may be confusing (the uplink of what)
> -
> > Peer/Subscriber/Host-IPv6-Address perhaps?
> 
>   Just something more specific than "IPv6-Address".  There are a lot of
> possible uses for IPv6 addresses.  Having an attribute named just
> "IPv6-Address" will be confusing.

Or useful; maybe they're the same thing?

> 
> >
> >> IPv6-Route-Option-Preference
> > 	Per your review - I too agree that a signed integer is somewhat
> > confusing however this is a direct copy of a DHCP option 

I think it's actually from a Router Advertisement message, but no matter.

> from RFC 4191:
> 
>   OK.  Is this attribute intended to transport that DHCP option, or to
> mirror the functionality?
> 
>   There are no signed integers in RADIUS, and 16 bit integers are not
> recommended.  I would suggest instead that the RADIUS definition of the
> attribute be "2 octets", and that the definition refers to the
> appropriate section of RFC 4191.

Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
single octet.

> 
>   i.e. leave the practical use of the attribute unchanged.  But change
> the definition to refer to another specification, rather than
> duplicating the definition here.

That's a fine idea.

...

> >> Prefix-Lifetime-Service-Type
> > Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> > integer. IMO this is not a big change one way or another - I have no
> > objection to changing this.

Again, a single octet should suffice, no?

...

--
to unsubscribe send 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, 28 Sep 2009 07:05:13 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:03:40 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Bernard Aboba [mailto:[email-masked]] writes:
> > Somebody should note (might as well be me) that since the 1) the
> > document is not a protocol specification & 2) the intended status is
> > BCP, the use of RFC 2118 keywords is inappropriate to begin with.
> 
>   Here's a list of RFCs that:
> 
>     (a) are Status: BCP
>     (b) have the word "guidelines" in their title
>     (c) use RFC 2119 keywords
>     (d) are relatively recent
> 
> 	http://tools.ietf.org/html/rfc3470
> 
> 	http://tools.ietf.org/html/rfc3552
> 
> 	http://tools.ietf.org/html/rfc4107
> 
> 	http://tools.ietf.org/html/rfc4181
> 
> 	http://tools.ietf.org/html/rfc4395
> 
> 	http://tools.ietf.org/html/rfc5226
> 
> 	http://tools.ietf.org/html/rfc5405
> 
> 	http://tools.ietf.org/html/rfc5625
> 
>   That's 8 documents in about 5 minutes of work.  I think your claim
> has
> been proven false.  The design guidelines document is following the
> current practice of the IETF.  The only way to disprove this is
> outright
> denial.

Speaking of which, perhaps you would like to address section 6 of RFC 2119.
Glad you've decided to do a little research once in a while, BTW ;-): you
have provided a treasure trove of material for RFC Errata.

>   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: Mon, 28 Sep 2009 06:36:52 +0000
Date: Mon, 28 Sep 2009 08:36:25 +0200
From: Alan DeKok <[email-masked]>
To: MILES DAVID <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked],  [email-masked], "David B. Nelson" <[email-masked]>,  [email-masked], Mark Townsley <[email-masked]>
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
>> Uplink-IPv6-Address instead of IPv6-Address
> 	I know the supporting text says "is assigned to the uplink of
> the user equipment" but uplink may be confusing (the uplink of what) -
> Peer/Subscriber/Host-IPv6-Address perhaps?

  Just something more specific than "IPv6-Address".  There are a lot of
possible uses for IPv6 addresses.  Having an attribute named just
"IPv6-Address" will be confusing.

> 
>> IPv6-Route-Option-Preference
> 	Per your review - I too agree that a signed integer is somewhat
> confusing however this is a direct copy of a DHCP option from RFC 4191:

  OK.  Is this attribute intended to transport that DHCP option, or to
mirror the functionality?

  There are no signed integers in RADIUS, and 16 bit integers are not
recommended.  I would suggest instead that the RADIUS definition of the
attribute be "2 octets", and that the definition refers to the
appropriate section of RFC 4191.

  i.e. leave the practical use of the attribute unchanged.  But change
the definition to refer to another specification, rather than
duplicating the definition here.

>> IPv6-Route-Option-Lifetime:
>> Auth-IPv6-Prefix-Valid-Lifetime:
...
> Again these 32-bit values are straight out of RFC 4191 and there is a
> requirement to support a value of infinity (0xffffffff). I think you
> could get away with a 24-bit value and a special recognition of
> infinity, but it is not desirable. If we adopt a fixed tag definition
> per Bernard's suggestion, do we still have a problem?

  It's still a new data type, but I think the alternatives would be worse.

>> Prefix-Lifetime-Service-Type
> Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> integer. IMO this is not a big change one way or another - I have no
> objection to changing this.

  OK.

  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: Mon, 28 Sep 2009 06:22:01 +0000
Content-class: urn:content-classes:message
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:54 +0800
From: "MILES DAVID" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>, "David B. Nelson" <[email-masked]>, <[email-masked]>, "Mark Townsley" <[email-masked]>

Sorry Alan,

I missed that one.

My comments on each point:

>Uplink-IPv6-Address instead of IPv6-Address
	I know the supporting text says "is assigned to the uplink of
the user equipment" but uplink may be confusing (the uplink of what) -
Peer/Subscriber/Host-IPv6-Address perhaps?

>IPv6-Route-Option-Preference
	Per your review - I too agree that a signed integer is somewhat
confusing however this is a direct copy of a DHCP option from RFC 4191:
Prf (Default Router Preference)
            2-bit signed integer.  Indicates whether to prefer this
            router over other default routers.  If the Router Lifetime
            is zero, the preference value MUST be set to (00) by the
            sender and MUST be ignored by the receiver.  If the Reserved
            (10) value is received, the receiver MUST treat the value as
            if it were (00).

  Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent

> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
> 
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
> 
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.

Again these 32-bit values are straight out of RFC 4191 and there is a
requirement to support a value of infinity (0xffffffff). I think you
could get away with a 24-bit value and a special recognition of
infinity, but it is not desirable. If we adopt a fixed tag definition
per Bernard's suggestion, do we still have a problem?

> Prefix-Lifetime-Service-Type
Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
integer. IMO this is not a big change one way or another - I have no
objection to changing this.

Cheers,

-David

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, 28 September 2009 3:13 PM
To: MILES DAVID
Cc: Bernard Aboba; [email-masked]; [email-masked]; David B.
Nelson; [email-masked]; Mark Townsley
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT
issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  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: Mon, 28 Sep 2009 06:06:35 +0000
Date: Mon, 28 Sep 2009 08:05:57 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Bernard Aboba [mailto:[email-masked]] writes:
> Somebody should note (might as well be me) that since the 1) the
> document is not a protocol specification & 2) the intended status is
> BCP, the use of RFC 2118 keywords is inappropriate to begin with.

  Here's a list of RFCs that:

    (a) are Status: BCP
    (b) have the word "guidelines" in their title
    (c) use RFC 2119 keywords
    (d) are relatively recent

	http://tools.ietf.org/html/rfc3470

	http://tools.ietf.org/html/rfc3552

	http://tools.ietf.org/html/rfc4107

	http://tools.ietf.org/html/rfc4181

	http://tools.ietf.org/html/rfc4395

	http://tools.ietf.org/html/rfc5226

	http://tools.ietf.org/html/rfc5405

	http://tools.ietf.org/html/rfc5625

  That's 8 documents in about 5 minutes of work.  I think your claim has
been proven false.  The design guidelines document is following the
current practice of the IETF.  The only way to disprove this is outright
denial.

  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: Mon, 28 Sep 2009 05:43:43 +0000
Date: Mon, 28 Sep 2009 07:42:32 +0200
From: Alan DeKok <[email-masked]>
To: MILES DAVID <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked],  [email-masked], "David B. Nelson" <[email-masked]>,  [email-masked], Mark Townsley <[email-masked]>
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  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: Mon, 28 Sep 2009 03:31:42 +0000
Content-class: urn:content-classes:message
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 11:30:40 +0800
From: "MILES DAVID" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>, "Mark Townsley" <[email-masked]>

Hi Bernard,

My email was simply an opportunity to prompt continued discussions from
Stockholm (things had been somewhat quiet).

To the question of tagged AVP,  your suggested rewording of
radext-design-07 :

For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
      
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present; 

        * The design make no assumption about the content of the
          data within tagged attributes."  

to require new AVP which implement tagged values must treat them as a
fixed/mandatory is to me the best approach _if_ it is decided that these
AVP should not fall under the guidelines of radext-extended-attributes.
My opinion is that radext-design-07 should be updated to include the
proposed text above. After that modification I believe the current text
in ipv6-access-01 around tags:

The Tag field is mandatory.  The Tag
      field values are greater than 0x00.

 Is sufficient to allow the adoption of this draft.

I see no other outstanding issues in the minutes or on the RADEXT issues
list for draft-lourdelet-radext-ipv6-access. Should I post your proposed
text as an issue to the list for tracking?

Cheers,

-David

--
to unsubscribe send 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, 28 Sep 2009 01:30:37 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700

This is a multi-part message in MIME format.

------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:[email-masked]]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.

------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>

<div>

<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#00B050'>Bernard Aboba [mailto:[email-masked]] &nbsp;writes:<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Arial Black","sans-serif";color:#1F497D'>WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems relevant:</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>6.
Guidance in the use of these Imperatives</span><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
Imperatives of the type defined in this memo must be used with care</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
and sparingly.&nbsp; In particular, they MUST only be used where it is</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
actually required for interoperation or to limit behavior which has</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
potential for causing harm (e.g., limiting retransmisssions)&nbsp; For</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
example, they must not be used to try to impose a particular method</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
on implementors where the method is not required for</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
interoperability.</span><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>[BA]
Are there specific uses of normative language in the document that you believe
are inappropriate? &nbsp; <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#00B050'>With the caveat that it&#8217;s been some time since I read the
draft, based upon my last review I&#8217;d have to say virtually all the uses
of RFC 2119 requirements language in the document are problematic.&nbsp; I plan
to go through the note in depth again this week.&nbsp; There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, easily
ignored (they are &#8220;guidelines&#8221;, after all).&nbsp; However, &nbsp;at
some point during the final discussions before the publication of RFC 5580 I realized
that the document, far from being a set of harmless suggestions on style, was in
fact a club to be used by pompous asses to keep people from getting real work
done.&nbsp; If you recall, my major arguments against the attributes defined in
5580 were based upon non-compliance w/the Design Guidelines document (yes, that
would make me one of those pompous asses &amp; I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and the
IESG for my misguided behavior).&nbsp; In fact, though, there was nothing
technically wrong with the geopriv attributes: they would have worked just
fine, thank you.&nbsp; Their only sin was deviation from a set of rules based
upon a highly suspect historical characterization of RADIUS development and a
simplistic (if not downright primitive processing model).&nbsp; At any rate,
removing the RFC 2119 language from the draft would go a long way toward making
the document truly harmless.<o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_00E8_01CA4015.C161E670--

--
to unsubscribe send 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, 27 Sep 2009 20:19:18 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: <[email-masked]>, Mark Townsley <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 13:18:16 -0700

 <[email-masked]>
MIME-Version: 1.0

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> No. Several people replied. They just supported the call without any comments, but they promised to comment.

In looking at the archive, these are the only people whose response indicated support of the document: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 

>Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  

The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 

And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br>&gt; No. Several people replied. They just supported the call without any comments, but they promised to comment.<br><br>In looking at the archive, these are the only people whose response indicated support of the document: <br><br>Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html<br>Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html<br>Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html<br><br>Aside from these individuals, who else has indicated support for the document?&nbsp; Please provide links to their emails. <br><br>&gt;Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).<br><br>The issue isn't how many editors the document has.&nbsp; The issue is the pace at which the document has evolved in response to feedback.&nbsp; <br><br>The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.&nbsp; If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.&nbsp; Providing deadlines without engaged people doesn't help. <br><br>And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. <br><br><br><br><br><br><br><br> 		 	   		  </body>
</html>
--_488386de-41e2-4753-a9c4-1561c6b41365_--

--
to unsubscribe send 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, 27 Sep 2009 16:43:49 +0000
Date: Sun, 27 Sep 2009 09:43:13 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
Reply-To: Behcet Sarikaya <[email-masked]>
Subject: Re: IPv6 Address Option
To: Bernard Aboba <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: [email-masked], Mark Townsley <[email-masked]>

Hi Bernard,

>
>From: Bernard Aboba <[email-masked]>
>To: [email-masked]; "[email-masked]" <[email-masked]>; David B. Nelson <[email-masked]>
>Cc: [email-masked]; Mark Townsley <[email-masked]>
>Sent: Saturday, September 26, 2009 7:21:27 PM
>Subject: RE: IPv6 Address Option
>
> >
>> A few months back some of us expressed a desire to proceed with the
>> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
>> item. 
>
>On June 25, 2009 there was a WG call for interest in the document: 
>http://ops.ietf.org/lists/radiusext/2009/msg00273.html
>
>Only one person other than yourself and the authors replied to the call for interest. 
>

No. Several people replie. They just supported the call without any comments, but they promised to comment.

>In addition, the document has not been revised in response to WG comments. 
>
>> In the recent Broadband Forum meeting in Tokyo it was announced
>> that the BBF will seek to finalize their document on IPv6 for PPP
>> environments (to which I am co-editor). With the lack of some essential
>> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
>> a hard place.
>
>If there was interest from the Broadband Forum, why has noone bothered to
>respond to the call for interest or to revise the document? 
>
>> Delaying the IPv6 for PPP document much beyond November is not an option
>
>If that is the case, why are the concerned parties not doing more to move it forward? 
>
>> I am happy to work with the current authors to create a draft which can be fast tracked.
>
>If you're volunteering to act as editor, that would be great.  Next step would be to issue a 
>version of the document addressing outstanding comments.  We can then discuss the 
>document at the October 13 Virtual Interim meeting. 
>
>

Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

Regards,

Behcet

--
to unsubscribe send 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, 27 Sep 2009 16:12:07 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Agenda for Interim Meeting - Take Two
Date: Sun, 27 Sep 2009 09:11:40 -0700

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Strawman Agenda

8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Agenda Bash
   Document Status 

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

Under Consideration for Adoption (30 minutes)

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

9:30 AM - 9:40 AM Requirements for IPv6 over PPP, David Miles (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

9:40 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<pre>Strawman Agenda<br><br>8:00 AM - 8:20 AM  Preliminaries<br>   Jabber scribe<br>   Agenda Bash<br>   Document Status <br><br>Documents completing IETF Last Call (20 minutes)<br><br>8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-design<br><br>Documents Completing WG Last Call (20 minutes)<br><br>8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-radsec<br><br>8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><br>9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-tcp-transport<br><br>WG Work Items (20 minutes)<br><br>9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<br><br>Under Consideration for Adoption (30 minutes)<br><br>9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-dtls<br><br>9:30 AM - 9:40 AM Requirements for IPv6 over PPP, David Miles (10 minutes)<br>http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access<br><br>9:40 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)<br>http://tools.ietf.org/html/draft-aboba-radext-wlan<br><br><br></pre><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_ab60308e-9082-46a5-8e1b-ccdf8704a708_--

--
to unsubscribe send 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, 27 Sep 2009 15:58:37 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 08:58:00 -0700

 <008901ca3f50$a322c960$e9685c20$@net>
MIME-Version: 1.0

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WRT this document, section 6 of RFC 2119 (sorry about the typo
above) seems relevant:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this
memo must be used with care

   and sparingly.  In particular,
they MUST only be used where it is

   actually required for interoperation or
to limit behavior which has

   potential for causing harm (e.g.,
limiting retransmisssions)  For

   example, they must not be used to try
to impose a particular method

   on implementors where the method is not
required for

   interoperability.

[BA] Are there specific uses of normative language in the document that you believe are inappropriate?  

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br><div class="ecxSection1"><div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;"><div><div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;"><p class="ecxMsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 10pt; font-family: 'Verdana','sans-serif';">
</span><span style="font-size: 10pt; font-family: 'Arial Black','sans-serif'; color: rgb(31, 73, 125);">WRT this document, section 6 of RFC 2119 (sorry about the typo
above) seems relevant:</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">6. Guidance in the use of these Imperatives</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; Imperatives of the type defined in this
memo must be used with care</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; and sparingly.&nbsp; In particular,
they MUST only be used where it is</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; actually required for interoperation or
to limit behavior which has</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; potential for causing harm (e.g.,
limiting retransmisssions)&nbsp; For</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; example, they must not be used to try
to impose a particular method</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; on implementors where the method is not
required for</span></p>

<p class="ecxMsoNormal" style=""><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp; interoperability.</span></p>

<p class="ecxMsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 10pt; font-family: 'Verdana','sans-serif';">&nbsp;</span></p><p class="ecxMsoNormal" style="margin-bottom: 12pt;"><br><span style="font-size: 10pt; font-family: 'Verdana','sans-serif';"></span></p>[BA] Are there specific uses of normative language in the document that you believe are inappropriate? &nbsp;

</div>

</div>

</div>

</div> 		 	   		  </body>
</html>
--_80404be2-30c3-4199-a317-19e38825fbf0_--

--
to unsubscribe send 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, 27 Sep 2009 15:47:24 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:46:39 -0700

 <[email-masked]>
MIME-Version: 1.0

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Old text:
> 
>    New attributes SHOULD NOT use this tagging method because of the
>    limitations described above.
> 
> New text:
> 
>    Where these limitations do not apply, new attributes MAY use this
>    tagging method, though it is NOT RECOMMENDED.  Where the above
>    limitations apply, this tagging method SHOULD NOT be used.

Here is the original text of Section 2.1.2:

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values, because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (assuming the tag is optional).

   Other limitations of the tagging mechanism are that when integer
   values are tagged, the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.
"

How about this? 

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.
   As stated in [RFC2868] Section 3.3:

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values, because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (e.g. where the first byte of the following
   String field falls in the range of 0x00 through 0x1F). 

   Other limitations of the tagging mechanism are that when integer
   values are tagged, the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
      
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present; 

        * The design make no assumption about the content of the
          data within tagged attributes."  

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
&gt; Old text:<br>&gt; <br>&gt;    New attributes SHOULD NOT use this tagging method because of the<br>&gt;    limitations described above.<br>&gt; <br>&gt; New text:<br>&gt; <br>&gt;    Where these limitations do not apply, new attributes MAY use this<br>&gt;    tagging method, though it is NOT RECOMMENDED.  Where the above<br>&gt;    limitations apply, this tagging method SHOULD NOT be used.<br><br>Here is the original text of Section 2.1.2:<br><br>"<pre>2.1.2.  Tagging Mechanism<br><br>   [RFC2868] defines an attribute grouping mechanism based on the use of<br>   a one octet tag value.  Tunnel attributes that refer to the same<br>   tunnel are grouped together by virtue of using the same tag value.<br><br>   This tagging mechanism has some drawbacks.  There are a limited<br>   number of unique tags (31).  The tags are not well suited for use<br>   with arbitrary binary data values, because it is not always possible<br>   to tell if the first byte after the Length is the tag or the first<br>   byte of the untagged value (assuming the tag is optional).<br><br>   Other limitations of the tagging mechanism are that when integer<br>   values are tagged, the value portion is reduced to three bytes<br>   meaning only 24-bit numbers can be represented.  The tagging<br>   mechanism does not offer an ability to create nested groups of<br>   attributes.  Some RADIUS implementations treat tagged attributes as<br>   having additional data types tagged-string and tagged-integer.  These<br>   types increase the complexity of implementing and managing RADIUS<br>   systems.<br><br>   New attributes SHOULD NOT use this tagging method because of the<br>   limitations described above.<br></pre>"<br><br>How about this? <br><br><pre>"2.1.2.  Tagging Mechanism<br><br>   [RFC2868] defines an attribute grouping mechanism based on the use of<br>   a one octet tag value.  Tunnel attributes that refer to the same<br>   tunnel are grouped together by virtue of using the same tag value.<br>   As stated in [RFC2868] Section 3.3:<br><br>      The Tag field is one octet in length and is intended to provide a<br>      means of grouping attributes in the same packet which refer to the<br>      same tunnel.  If the value of the Tag field is greater than 0x00<br>      and less than or equal to 0x1F, it SHOULD be interpreted as<br>      indicating which tunnel (of several alternatives) this attribute<br>      pertains.  If the Tag field is greater than 0x1F, it SHOULD be<br>      interpreted as the first byte of the following String field.<br><br>   This tagging mechanism has some drawbacks.  There are a limited<br>   number of unique tags (31).  The tags are not well suited for use<br>   with arbitrary binary data values, because it is not always possible<br>   to tell if the first byte after the Length is the tag or the first<br>   byte of the untagged value (e.g. where the first byte of the following<br>   String field falls in the range of 0x00 through 0x1F). <br><br>   Other limitations of the tagging mechanism are that when integer<br>   values are tagged, the value portion is reduced to three bytes<br>   meaning only 24-bit numbers can be represented.  The tagging<br>   mechanism does not offer an ability to create nested groups of<br>   attributes.  Some RADIUS implementations treat tagged attributes as<br>   having additional data types tagged-string and tagged-integer.  These<br>   types increase the complexity of implementing and managing RADIUS<br>   systems.<br><br>   For these reasons, the tagging scheme described in RFC 2868 is<br>   not suitable for use as a generic grouping mechanism.  Where<br>   a tagging scheme is required for use with arbitrary data types,<br>   it is RECOMMENDED that:<br>      <br>        * A fixed tagging field be used so as to remove potential<br>          interoperability issues associated with determining whether<br>          an optional tag is present; <br><br>        * The design make no assumption about the content of the<br>          data within tagged attributes."  <br><br><br></pre>
<br> 		 	   		  </body>
</html>
--_289e488d-de66-4fff-bd63-021df62db0b7_--

--
to unsubscribe send 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, 27 Sep 2009 12:58:23 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:57:24 -0400

Bernard Aboba writes...

> Either the Design Guidelines advice is appropriate or it isn't. 
>
> If it isn't right, then we should fix it, because eventually
> it will become an RFC and "racing against" it won't work any
> more.  If it is right, then we should try to adhere to the
> guidelines -- that's what they are there for.

+1

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

Delivery-date: Sun, 27 Sep 2009 09:18:13 +0000
Date: Sun, 27 Sep 2009 11:17:24 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: IPv6

Bernard Aboba wrote:
> Alan DeKok said:
> 
> "I suggest racing against the design guidelines document. After all,
> it's only a draft. If the IPv6 document can get published first, then
> the design guidelines matter a lot less."
> 
> [BA] Either the Design Guidelines advice is appropriate or it isn't.

  The comment was an attempt at humor, to counter the vitriol directed
at the design guidelines document.

> In this particular case, my take is that the Design Guidelines document
> is saying "don't do precisely what RFC 2868 did".  That is quite
> sensible.  However, it might also be helpful to say "Here are the
> problems that were caused by RFC 2868's scheme, and here is some advice
> to avoid those issues".  That way, until we finish the Extended
> Attributes document, we'll have some way to address these kind of
> situations.

  Update 2.1.1 Tag Mechanism:

Old text:

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

New text:

   Where these limitations do not apply, new attributes MAY use this
   tagging method, though it is NOT RECOMMENDED.  Where the above
   limitations apply, this tagging method SHOULD NOT be used.

  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: Sun, 27 Sep 2009 08:59:27 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 15:57:45 +0700

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:[email-masked]] writes:
Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.

[BA] Where does it say that BCPs can't contain normative keywords?  Lots of
other BCPs seem to use them. 

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;
border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Arial Black","sans-serif";color:#1F497D'>Bernard Aboba
[mailto:[email-masked]] writes:<br>
</span><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>Somebody should note (might as well be me) that since the 1) the
document is not a protocol specification &amp; 2) the intended status is BCP,
the use of RFC 2118 keywords is inappropriate to begin with.</span><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><br>
[BA] Where does it say that BCPs can't contain normative keywords?&nbsp; Lots
of other BCPs seem to use them. <br>
<br>
</span><span style='font-size:10.0pt;font-family:"Arial Black","sans-serif";
color:#1F497D'>WRT this document, section 6 of RFC 2119 (sorry about the typo
above) seems relevant:<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>6. Guidance in the use of these Imperatives<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; Imperatives of the type defined in this
memo must be used with care<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; and sparingly.&nbsp; In particular,
they MUST only be used where it is<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; actually required for interoperation or
to limit behavior which has<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; potential for causing harm (e.g.,
limiting retransmisssions)&nbsp; For<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; example, they must not be used to try
to impose a particular method<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; on implementors where the method is not
required for<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; interoperability.<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_008A_01CA3F8B.4F81A160--

--
to unsubscribe send 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, 27 Sep 2009 08:02:18 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re:  IPv6
Date: Sun, 27 Sep 2009 01:01:45 -0700

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alan DeKok said:

"I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less."

[BA] Either the Design Guidelines advice is appropriate or it isn't. 

If it isn't right, then we should fix it, because eventually it will become an RFC and "racing against" it won't work any more. 
If it is right, then we should try to adhere to the guidelines -- that's what they are there for. 

In this particular case, my take is that the Design Guidelines document is saying "don't do precisely what RFC 2868 did".  That is quite sensible.  However, it might also be helpful to say "Here are the problems that were caused by RFC 2868's scheme, and here is some advice to avoid those issues".  That way, until we finish the Extended Attributes document, we'll have some way to address these kind of situations. 

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Alan DeKok said:<br><br>"I suggest racing against the design guidelines document.  After all,<br>it's only a draft.  If the IPv6 document can get published first, then<br>the design guidelines matter a lot less."<br><br>[BA] Either the Design Guidelines advice is appropriate or it isn't. <br><br>If it isn't right, then we should fix it, because eventually it will become an RFC and "racing against" it won't work any more. <br>If it is right, then we should try to adhere to the guidelines -- that's what they are there for. <br><br>In this particular case, my take is that the Design Guidelines document is saying "don't do precisely what RFC 2868 did".&nbsp; That is quite sensible.&nbsp; However, it might also be helpful to say "Here are the problems that were caused by RFC 2868's scheme, and here is some advice to avoid those issues".&nbsp; That way, until we finish the Extended Attributes document, we'll have some way to address these kind of situations. <br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_--

--
to unsubscribe send 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, 27 Sep 2009 07:49:03 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:48:38 -0700

 <006401ca3f45$408ff530$c1afdf90$@net>
MIME-Version: 1.0

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Somebody should note (might
as well be me) that since the 1) the document is not a protocol specification
& 2) the intended status is BCP, the use of RFC 2118 keywords is inappropriate
to begin with.

[BA] Where does it say that BCPs can't contain normative keywords?  Lots of other BCPs seem to use them. 

 

 		 	   		  
--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<span style="font-size: 10pt; font-family: 'Verdana','sans-serif';"><br>
<span style="color: rgb(31, 73, 125);"></span></span><div class="ecxSection1"><div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">

<p class="ecxMsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);">Somebody should note (might
as well be me) that since the 1) the document is not a protocol specification
&amp; 2) the intended status is BCP, the use of RFC 2118 keywords is inappropriate
to begin with.</span></p>

<p class="ecxMsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 10pt; font-family: 'Verdana','sans-serif';"><br>
[BA] Where does it say that BCPs can't contain normative keywords?&nbsp; Lots of other BCPs seem to use them. <br>
<br>
<br>
<br>
</span></p>

<table class="ecxMsoNormalTable" style="border-style: solid none none; border-color: black -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium;" border="1" cellpadding="0">
 <tbody><tr>
  <td style="border: medium none ; padding: 0.75pt;"><br></td>
 </tr>
</tbody></table>

<p class="ecxMsoNormal">&nbsp;</p>

</div>

</div> 		 	   		  </body>
</html>
--_2a5ac828-0a61-4a61-abdb-6d211e67d088_--

--
to unsubscribe send 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, 27 Sep 2009 07:47:15 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:46:36 -0700

 <[email-masked]>
MIME-Version: 1.0

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   The draft-lourdelet document defines a new data type.  8-bit tag,
> followed by 32-bit integer.  While this is arguably better than the RFC
> 2868 form, it still is a new data type.  And the document discourages
> new data types.

OK.  So the issue is not the use of RFC 2868 tags. 

>   Maybe the document needs to say:
> 
>    In order to meet these objectives, this document needs to cover not
>    only the science of attribute design, but also the art.  As a result,
>    in addition to covering the most frequently encountered issues, this
>    document attempts to provide some of the considerations motivating
>    the guidelines.  Reviewers are expected to weigh the cost and
>    benefits of following or ignoring the guidelines, as nearly all
>    suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
>    intent is for the guidelines to help authors create better documents.
>    This intent means that reviewers can choose to ignore some of the
>    recommendations herein.  When this is done, their review MUST be
>    accompanied by an explanation as to why the guidelines were not
>    followed, and why following the guidelines would have resulted in
>    a worse architecture.

Personally, I don't think this text is necessary; RFC 2119 defines the
meaning of SHOULD. 

> >  Perhaps the Design Guidelilnes document should be more
> > clear about exactly what the flaws were in the RFC 2868 scheme that the
> > SHOULD NOT applies to. 
> 
>   Or, it could say that the tagging mechanism MAY be used when none of
> the above limitations apply.

Or, it might describe how a single octet tagging scheme might avoid the
problems of RFC 2868. 
 		 	   		  
--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
&gt;   The draft-lourdelet document defines a new data type.  8-bit tag,<br>&gt; followed by 32-bit integer.  While this is arguably better than the RFC<br>&gt; 2868 form, it still is a new data type.  And the document discourages<br>&gt; new data types.<br><br>OK.&nbsp; So the issue is not the use of RFC 2868 tags. <br><br>&gt;   Maybe the document needs to say:<br>&gt; <br>&gt;    In order to meet these objectives, this document needs to cover not<br>&gt;    only the science of attribute design, but also the art.  As a result,<br>&gt;    in addition to covering the most frequently encountered issues, this<br>&gt;    document attempts to provide some of the considerations motivating<br>&gt;    the guidelines.  Reviewers are expected to weigh the cost and<br>&gt;    benefits of following or ignoring the guidelines, as nearly all<br>&gt;    suggestions here are of the form "SHOULD" or "SHOULD NOT".  The<br>&gt;    intent is for the guidelines to help authors create better documents.<br>&gt;    This intent means that reviewers can choose to ignore some of the<br>&gt;    recommendations herein.  When this is done, their review MUST be<br>&gt;    accompanied by an explanation as to why the guidelines were not<br>&gt;    followed, and why following the guidelines would have resulted in<br>&gt;    a worse architecture.<br><br>Personally, I don't think this text is necessary; RFC 2119 defines the<br>meaning of SHOULD. <br><br>&gt; &gt;  Perhaps the Design Guidelilnes document should be more<br>&gt; &gt; clear about exactly what the flaws were in the RFC 2868 scheme that the<br>&gt; &gt; SHOULD NOT applies to. <br>&gt; <br>&gt;   Or, it could say that the tagging mechanism MAY be used when none of<br>&gt; the above limitations apply.<br><br>Or, it might describe how a single octet tagging scheme might avoid the<br>problems of RFC 2868. <br> 		 	   		  </body>
</html>
--_84ad55d2-3394-4fe9-b938-55e63f669c2a_--

--
to unsubscribe send 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, 27 Sep 2009 07:37:45 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 14:36:16 +0700

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

>"New attributes SHOULD NOT use this tagging method...". Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that
described in RFC 2868.  So does the Design Guidelines advice even apply
here?  Perhaps the Design Guidelilnes document should be more clear about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT
applies to.  

Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.

------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>Bernard Aboba <a
href="mailto:[mailto://[email-masked]%5d"><span style='color:#7030A0;
text-decoration:none'>[mailto://[email-masked]]</span></a> writes:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>&gt;&quot;New attributes SHOULD NOT use
this tagging method...&quot;. Which is it?<br>
<br>
The tagging scheme in draft-lourdelet does not have the same flaws as that
described in RFC 2868.&nbsp; So does the Design Guidelines advice even apply
here?&nbsp; Perhaps the Design Guidelilnes document should be more clear about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies
to.&nbsp; <br>
<br>
<span style='color:#1F497D'><o:p></o:p></span></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Arial Black","sans-serif";color:#7030A0'>Somebody should note (might
as well be me) that since the 1) the document is not a protocol specification
&amp; 2) the intended status is BCP, the use of RFC 2118 keywords is inappropriate
to begin with.<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><br>
<br>
<br>
<br>
<br>
<o:p></o:p></span></p>

<table class=MsoNormalTable border=1 cellpadding=0 style='border:none;
 border-top:solid black 1.0pt'>
 <tr>
  <td style='border:none;padding:.75pt .75pt .75pt .75pt'></td>
 </tr>
</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0065_01CA3F7F.ECEECD30--

--
to unsubscribe send 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, 27 Sep 2009 07:14:59 +0000
Date: Sun, 27 Sep 2009 09:14:25 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: IPv6 Address Option

Bernard Aboba wrote:
>>"New attributes SHOULD NOT use this tagging method...". Which is it?
> 
> The tagging scheme in draft-lourdelet does not have the same flaws as
> that described in RFC 2868.  So does the Design Guidelines advice even
> apply here?

  The draft-lourdelet document defines a new data type.  8-bit tag,
followed by 32-bit integer.  While this is arguably better than the RFC
2868 form, it still is a new data type.  And the document discourages
new data types.

  As with most protocol design, there is room for an intelligent
application of checks and balances.  The issues associated with defining
a new data type should be weighed against the issues associated with
re-using a deprecated data type.

  An application of intelligence is suggested.  A thoughtless
application of the guidelines is not appropriate, as is a thoughtless
rejection of it.  I will note that the *only* "MUST" text in the
document is:

   1) provisioning of new services MUST be done in the IETF

   2) service provisioning MUST NOT be done in Access-Reject.

  All other "MUST" text in the documents are quotes from other RFCs.

  Hence, the suggestions of the guidelines documents are SHOULD, SHOULD
NOT, etc.  A reviewer following the guidelines document is perfectly
free to *not* follow its suggestions, if he believes that doing so would
be worse than the alternatives.

  Maybe the document needs to say:

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.  Reviewers are expected to weigh the cost and
   benefits of following or ignoring the guidelines, as nearly all
   suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
   intent is for the guidelines to help authors create better documents.
   This intent means that reviewers can choose to ignore some of the
   recommendations herein.  When this is done, their review MUST be
   accompanied by an explanation as to why the guidelines were not
   followed, and why following the guidelines would have resulted in
   a worse architecture.

>  Perhaps the Design Guidelilnes document should be more
> clear about exactly what the flaws were in the RFC 2868 scheme that the
> SHOULD NOT applies to. 

  Or, it could say that the tagging mechanism MAY be used when none of
the above limitations apply.

  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: Sun, 27 Sep 2009 06:41:33 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re:  IPv6 Address Option
Date: Sat, 26 Sep 2009 23:41:19 -0700

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>"New attributes SHOULD NOT use this tagging method...".  Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that described in RFC 2868.  So does the Design Guidelines advice even apply here?  Perhaps the Design Guidelilnes document should be more clear about exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies to.  

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
&gt;"New attributes SHOULD NOT use this tagging method...".  Which is it?<br><br>The tagging scheme in draft-lourdelet does not have the same flaws as that described in RFC 2868.&nbsp; So does the Design Guidelines advice even apply here?&nbsp; Perhaps the Design Guidelilnes document should be more clear about exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies to.&nbsp; <br><br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_--

--
to unsubscribe send 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, 27 Sep 2009 06:41:31 +0000
Date: Sun, 27 Sep 2009 08:41:16 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  [email-masked], [email-masked],  [email-masked],  'Maglione Roberta' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Alan DeKok [mailto:[email-masked]] writes:
>> After all, it's only a draft.  
> 
> Hmm.  That didn't seem to be relevant when you used it a club (its real
> purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

  Are my comments really that influential?

  I've come along in the world.

  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: Sun, 27 Sep 2009 06:40:56 +0000
Date: Sun, 27 Sep 2009 08:39:58 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  [email-masked], [email-masked],  [email-masked],  'Maglione Roberta' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Actually, _you_ made the claim, I just quoted it.

  Nonsense.

  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: Sun, 27 Sep 2009 05:34:36 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'MILES DAVID'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Maglione Roberta'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 12:32:24 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:[email-masked]] writes:
> >
> >> Glen Zorn wrote:
> >>> Even more interestingly, your latest missive seems to strongly
> imply
> >> that
> >>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> >> barrier
> >>> to adoption" of new attributes designed following them...
> >>   Perhaps there's an IETF process to obtain WG consensus and update
> >> published documents?
> >
> > What do you mean?
> 
>   Later documents can update earlier documents.  If the design
> guidelines is as catastrophic as you claim, 

Actually, _you_ made the claim, I just quoted it.

> later documents can update
> it, and define new attributes that don't follow it's recommendations.
> 
>   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: Sun, 27 Sep 2009 03:29:58 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'MILES DAVID'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Maglione Roberta'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 10:27:37 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > ... but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> > the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> > this tagging method...".  Which is it?
> 
>   I suggest racing against the design guidelines document.  

What a great idea!  Since the Mis-Guidelines draft is in IESG evaluation &
our draft has yet to be accepted as a WG item, it's a race we're sure to
win!  A more likely scenario: we change our draft to match your "review",
then the Mis-Guidelines draft is published as an ACP (Alan's Current
Practice) & presto, we get to change it again.  It would be a classic of
obstructionism, if only it weren't so obvious.

> After all, it's only a draft.  

Hmm.  That didn't seem to be relevant when you used it a club (its real
purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

...

--
to unsubscribe send 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, 27 Sep 2009 00:22:37 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, "[email-masked]" <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: <[email-masked]>, Mark Townsley <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:21:27 -0700

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item. 

On June 25, 2009 there was a WG call for interest in the document: 
http://ops.ietf.org/lists/radiusext/2009/msg00273.html

Only one person other than yourself and the authors replied to the call for interest. 

In addition, the document has not been revised in response to WG comments. 

> In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.

If there was interest from the Broadband Forum, why has noone bothered to
respond to the call for interest or to revise the document? 

> Delaying the IPv6 for PPP document much beyond November is not an option

If that is the case, why are the concerned parties not doing more to move it forward? 

> I am happy to work with the current authors to create a draft which can be fast tracked.

If you're volunteering to act as editor, that would be great.  Next step would be to issue a 
version of the document addressing outstanding comments.  We can then discuss the 
document at the October 13 Virtual Interim meeting. 

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
&gt; A few months back some of us expressed a desire to proceed with the<br>&gt; draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG<br>&gt; item. <br><br>On June 25, 2009 there was a WG call for interest in the document: <br>http://ops.ietf.org/lists/radiusext/2009/msg00273.html<br><br>Only one person other than yourself and the authors replied to the call for interest. <br><br>In addition, the document has not been revised in response to WG comments. <br><br>&gt; In the recent Broadband Forum meeting in Tokyo it was announced<br>&gt; that the BBF will seek to finalize their document on IPv6 for PPP<br>&gt; environments (to which I am co-editor). With the lack of some essential<br>&gt; RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and<br>&gt; a hard place.<br><br>If there was interest from the Broadband Forum, why has noone bothered to<br>respond to the call for interest or to revise the document? <br><br>&gt; Delaying the IPv6 for PPP document much beyond November is not an option<br><br>If that is the case, why are the concerned parties not doing more to move it forward? <br><br>&gt; I am happy to work with the current authors to create a draft which can be fast tracked.<br><br>If you're volunteering to act as editor, that would be great.&nbsp; Next step would be to issue a <br>version of the document addressing outstanding comments.&nbsp; We can then discuss the <br>document at the October 13 Virtual Interim meeting. <br><br> 		 	   		  </body>
</html>
--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_--

--
to unsubscribe send 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, 26 Sep 2009 14:28:04 +0000
Date: Sat, 26 Sep 2009 16:27:10 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  [email-masked], [email-masked],  [email-masked],  'Maglione Roberta' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Alan DeKok [mailto:[email-masked]] writes:
> 
>> Glen Zorn wrote:
>>> Even more interestingly, your latest missive seems to strongly imply
>> that
>>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
>> barrier
>>> to adoption" of new attributes designed following them...
>>   Perhaps there's an IETF process to obtain WG consensus and update
>> published documents?
> 
> What do you mean?

  Later documents can update earlier documents.  If the design
guidelines is as catastrophic as you claim, later documents can update
it, and define new attributes that don't follow it's recommendations.

  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, 26 Sep 2009 13:11:03 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'MILES DAVID'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Maglione Roberta'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 20:09:11 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Even more interestingly, your latest missive seems to strongly imply
> that
> > adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> barrier
> > to adoption" of new attributes designed following them...
> 
>   Perhaps there's an IETF process to obtain WG consensus and update
> published documents?

What do you mean?

--
to unsubscribe send 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, 26 Sep 2009 10:51:41 +0000
Date: Sat, 26 Sep 2009 12:51:16 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  [email-masked], [email-masked],  [email-masked],  'Maglione Roberta' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> Even more interestingly, your latest missive seems to strongly imply that
> adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
> to adoption" of new attributes designed following them...

  Perhaps there's an IETF process to obtain WG consensus and update
published documents?

  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, 26 Sep 2009 10:40:52 +0000
Date: Sat, 26 Sep 2009 12:40:17 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'MILES DAVID' <[email-masked]>,  [email-masked], [email-masked],  [email-masked],  'Maglione Roberta' <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

Glen Zorn wrote:
> ... but draft-ietf-radext-design-08, section 2.1.2 says (talking about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
> this tagging method...".  Which is it?  

  I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less.

  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, 26 Sep 2009 10:10:15 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'MILES DAVID'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Maglione Roberta'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:08:56 +0700

I wrote:

> Alan DeKok [mailto://[email-masked]] writes:
> 
> >   Is there a response to my review?
> >
> > http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> >
> >   Addressing the minor issues brought up in the review would allow
> > server implementations to support the document by simply updating
> their
> > dictionaries.  As it stands now, new data types will have to be
> > defined,
> > which can be a significant barrier to adoption.
> 
> In your review you say "Defining a tag field *and* a 32-bit integer
> means
> that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section
> 3.1 for the historical definition. It would seem to be OK to have a 24-
> bit
> lifetime.  That would allow everyone to use this attribute by simply
> updating their dictionaries, rather than writing new code to handle a
> new
> format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> this tagging method...".  Which is it?

Even more interestingly, your latest missive seems to strongly imply that
adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
to adoption" of new attributes designed following them...

--
to unsubscribe send 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, 26 Sep 2009 09:55:26 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'MILES DAVID'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Maglione Roberta'" <[email-masked]>, <[email-masked]>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 16:53:34 +0700

Alan DeKok [mailto://[email-masked]] writes:

>   Is there a response to my review?
> 
> http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> 
>   Addressing the minor issues brought up in the review would allow
> server implementations to support the document by simply updating their
> dictionaries.  As it stands now, new data types will have to be
> defined,
> which can be a significant barrier to adoption.

In your review you say "Defining a tag field *and* a 32-bit integer means
that you're
re-defining the meaning of a tag + integer attribute.  See RFC 2868, Section
3.1 for the historical definition. It would seem to be OK to have a 24-bit
lifetime.  That would allow everyone to use this attribute by simply
updating their dictionaries, rather than writing new code to handle a new
format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking about
the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
this tagging method...".  Which is it?  

...

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

Delivery-date: Sat, 26 Sep 2009 07:18:08 +0000
Date: Sat, 26 Sep 2009 09:16:53 +0200
From: Alan DeKok <[email-masked]>
To: MILES DAVID <[email-masked]>
CC: [email-masked], [email-masked],  [email-masked],  Maglione Roberta <[email-masked]>, [email-masked]
Subject: Re: IPv6 Address Option

  Is there a response to my review?

http://ops.ietf.org/lists/radiusext/2009/msg00401.html

  Addressing the minor issues brought up in the review would allow
server implementations to support the document by simply updating their
dictionaries.  As it stands now, new data types will have to be defined,
which can be a significant barrier to adoption.

MILES DAVID wrote:
> Folk,
> 
> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item. In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.
> 
> Delaying the IPv6 for PPP document much beyond November is not an option
> for a large number of operators who wish to get some IPv6 deployment
> going. With this goal in mind I ask the WG and chairs to adopt this
> draft as a starting point with a goal of getting to WGLC within the
> coming months (after Hiroshima IETF). If it needs to be simplified down
> to the essential AVP I am happy to work with the current authors to
> create a draft which can be fast tracked.
> 
> The alternatives are ugly IMO
> 
> 
> Regards
> 
> -David Miles
> 
> --
> to unsubscribe send 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, 24 Sep 2009 21:30:35 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT WG Virtual Interim Agenda:  October 13, 2009
Date: Thu, 24 Sep 2009 14:29:22 -0700

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Agenda
Meeting agenda is available here: 
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

Slides
Slides are available for download here: 
http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/

AUDIO INFORMATION 

To
join a meeting from your phone, dial in using the following information:

            Phone:   +18883203585 [English]

            Phone:   +14257063500 [English]

            Find a local
phone number for your region

            Conference ID:    9182049

            Passcode:           Passcode is not required.

            Note: If you have an account on this
corporate network, use your PIN to join. Have you set
your PIN?
Web Conferencing information (optional)
To join the online meeting, click on the following URL: 

Join the meeting

 To install the Office Live Meeting client click here. 

TROUBLESHOOTING 

Unable
to join the meeting?  Start Office Live
Meeting and join the meeting with the following information:

            Meeting ID:        63840ffb128647eca56d51898b461c42

            Entry Code:        6650

            Location:            meet:sip:[email-masked];gruu;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=6650

If
you still cannot enter the meeting, contact support: 

Live Meeting Support

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 12"><meta name="Originator" content="Microsoft Word 12"><link rel="File-List" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="themeData" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;
	mso-font-charset:1;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:variable;
	mso-font-signature:0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 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:-520081665 -1073717157 41 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	mso-themecolor:hyperlink;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	mso-themecolor:followedhyperlink;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle16
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Arial","sans-serif";
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:-2;
	mso-list-type:simple;
	mso-list-template-ids:-267617666;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:*;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:0in;
	text-indent:0in;}
@list l0:level1 lfo1
	{mso-level-numbering:continue;
	mso-level-text:?;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	mso-level-legacy:yes;
	mso-level-legacy-indent:.25in;
	mso-level-legacy-space:0in;
	margin-left:0in;
	text-indent:0in;
	font-family:Symbol;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}
</style>
<![endif]--><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><a href="http://r.office.microsoft.com/r/rlidOCSR2?clid=1033&amp;p1=livemeeting"><span style="color: blue;"></span></a><o:p></o:p></span>

<p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);">Agenda</span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><br></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;">Meeting agenda is available here: <br></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;">http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt<br><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"></span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><br></span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);">Slides</span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><br></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;">Slides are available for download here: <br></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;">http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/<br><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"></span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><br></span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);">AUDIO INFORMATION</span></b><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: navy;"> </span></b><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><o:p></o:p></span></b></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">To
join a meeting from your phone, dial in using the following information:<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Phone:<span style="">&nbsp;&nbsp; </span>+18883203585 [English]<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Phone:<span style="">&nbsp;&nbsp; </span>+14257063500 [English]<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><a href="https://cwa.microsoft.com/dialin"><span style="color: blue;">Find a local
phone number for your region</span></a><o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><o:p>&nbsp;</o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Conference ID:<span style="">&nbsp;&nbsp;&nbsp; </span>9182049<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Passcode:<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Passcode is not required.<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Note: If you have an account on this
corporate network, use your PIN to join. <a href="https://cwa.microsoft.com/dialin"><span style="color: blue;">Have you set
your PIN?</span></a></span></p><p class="MsoNormal" style="margin-bottom: 2pt;"><br></p><p class="MsoNormal" style="margin-bottom: 2pt;"></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);">Web Conferencing information (optional)</span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><br><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"></span></b></p><p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">To join the online meeting, click on the following URL: <o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><a href="meet:sip:[email-masked];gruu;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=6650"><span style="font-size: 11pt; color: blue;">Join the meeting</span></a><o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><o:p>&nbsp;</o:p></span></p><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">To install the Office Live Meeting client <a href="http://r.office.microsoft.com/r/rlidOCSR2?clid=1033&amp;p1=livemeeting"><span style="color: blue;">click here. <br></span></a></span><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><br></span></b></p><p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);">TROUBLESHOOTING</span></b><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: navy;"> </span></b><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><o:p></o:p></span></b></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">Unable
to join the meeting?<span style="">&nbsp; </span>Start Office Live
Meeting and join the meeting with the following information:<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Meeting ID:<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>63840ffb128647eca56d51898b461c42<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Entry Code:<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>6650<o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Location:<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><a href="meet:sip:[email-masked];gruu;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=6650">meet:sip:[email-masked];gruu;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=6650</a><o:p></o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><o:p>&nbsp;</o:p></span></p>

<p class="MsoNormal" style="margin-bottom: 2pt;"><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">If
you still cannot enter the meeting, contact support: <o:p></o:p></span></p>

<p class="MsoNormal" style="margin: 0in 0in 2pt 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-size: 9pt; font-family: Symbol;"><span style=""><span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal; -x-system-font: none;"></span></span></span><!--[endif]--><span style="font-size: 9pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"><a href="http://r.office.microsoft.com/r/rlidLiveMeeting?p1=12&amp;p2=en_us&amp;p3=LMInfo&amp;p4=supportserver"><span style="color: blue;">Live Meeting Support</span></a><o:p></o:p></span></p>

<p class="MsoNormal" style="margin: 10pt 0in 2pt;"><b><span style="font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: rgb(0, 77, 128);"><br></span></b></p><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_315b0f9e-25cb-427c-92e0-dfd18f076caf_--

--
to unsubscribe send 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, 23 Sep 2009 10:48:50 +0000
Content-class: urn:content-classes:message
Subject: IPv6 Address Option
Date: Wed, 23 Sep 2009 18:47:34 +0800
From: "MILES DAVID" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Maglione Roberta" <[email-masked]>, <[email-masked]>

Folk,

A few months back some of us expressed a desire to proceed with the
draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
item. In the recent Broadband Forum meeting in Tokyo it was announced
that the BBF will seek to finalize their document on IPv6 for PPP
environments (to which I am co-editor). With the lack of some essential
RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
a hard place.

Delaying the IPv6 for PPP document much beyond November is not an option
for a large number of operators who wish to get some IPv6 deployment
going. With this goal in mind I ask the WG and chairs to adopt this
draft as a starting point with a goal of getting to WGLC within the
coming months (after Hiroshima IETF). If it needs to be simplified down
to the essential AVP I am happy to work with the current authors to
create a draft which can be fast tracked.

The alternatives are ugly IMO

Regards

-David Miles

--
to unsubscribe send 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, 17 Sep 2009 15:54:32 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:54:08 -0700

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet, like the RADIUS type field.  While this limitation
>    results in an efficient encoding, there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also, an SDO can be comprised of multiple subgroups,
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
> 
>    These desires have led vendors to define the following non-standard
>    VSA formats:

How about this?

"Note that the Vendor type field in the recommended VSA format is only
a single octet, like the RADIUS type field.  While this limitation
results in an efficient encoding, there are situations in which a
vendor or SDO will eventually wish to define more than 255
attributes.  Also, an SDO can be comprised of multiple subgroups,
each of whom can desire autonomy over the definition of attributes
within their group.  The most interoperable way to address these
issues is for the vendor or SDO to request allocation of multiple
Vendor identifiers. 

However, instead of doing this, vendors have defined the following
non-standard VSA formats:"

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt;    Note that the Vendor type field in the recommended VSA format is only<br>&gt;    a single octet, like the RADIUS type field.  While this limitation<br>&gt;    results in an efficient encoding, there are situations in which a<br>&gt;    vendor or SDO will eventually wish to define more than 255<br>&gt;    attributes.  Also, an SDO can be comprised of multiple subgroups,<br>&gt;    each of whom can desire autonomy over the definition of attributes<br>&gt;    within their group.<br>&gt; <br>&gt;    These desires have led vendors to define the following non-standard<br>&gt;    VSA formats:<br><br>How about this?<br><br>"Note that the Vendor type field in the recommended VSA format is only<br>a single octet, like the RADIUS type field.  While this limitation<br>results in an efficient encoding, there are situations in which a<br>vendor or SDO will eventually wish to define more than 255<br>attributes.  Also, an SDO can be comprised of multiple subgroups,<br>each of whom can desire autonomy over the definition of attributes<br>within their group.&nbsp; The most interoperable way to address these<br>issues is for the vendor or SDO to request allocation of multiple<br>Vendor identifiers. <br><br>However, instead of doing this, vendors have defined the following<br>non-standard VSA formats:"<br></body>
</html>
--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_--

--
to unsubscribe send 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, 17 Sep 2009 15:51:31 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:51:10 -0700

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
>    lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
>    Vendor-Specific contents that are not in Type-Length-Value format.

How about this? 

All VSA schemes that do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since these formats will typically not be
implementable without RADIUS server code changes.  This includes all 
the above formats, as well as Vendor types of more than 8 bits, vendor 
lengths of less than 8 bits, vendor lengths of more than 8 bits and 
Vendor-Specific contents that are not in Type-Length-Value format. 

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt;    All of these formats are NOT RECOMMENDED.  All VSA formats that do<br>&gt;    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT<br>&gt;    RECOMMENDED formats include Vendor types of more than 8 bits, Vendor<br>&gt;    lengths of less than 8 bits, Vendor lengths of more than 8 bits, and<br>&gt;    Vendor-Specific contents that are not in Type-Length-Value format.<br><br>How about this? <br><br>All VSA schemes that do not follow the [RFC2865] recommendations<br>are NOT RECOMMENDED since these formats will typically not be<br>implementable without RADIUS server code changes.&nbsp; This includes all <br>the above formats, as well as Vendor types of more than 8 bits, vendor <br>lengths of less than 8 bits, vendor lengths of more than 8 bits and <br>Vendor-Specific contents that are not in Type-Length-Value format. <br></body>
</html>
--_939f895e-c564-4eec-b908-939ab189ece1_--

--
to unsubscribe send 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, 17 Sep 2009 15:46:46 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item
Date: Thu, 17 Sep 2009 08:45:07 -0700

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Deployment experience with RADIUS over TLS indicates that is useful
> for inter-server communication, such as inter-domain proxying across
> the Internet.  The large amounts of traffic, and long-lived
> connections are a good fit for TCP transport.  These situations
> commonly also require complete data privacy that can be supplied by
> TLS.
> 
> The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
> server communication is a bad fit, as there is usually insufficient
> traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
> communication is a bad fit, as it provides for no data privacy.  The
> only valid use-case for "bare" TCP, therefore, is on private, secured
> networks where there is simultaneously a large amount of traffic, and
> no need for data integrity or privacy.

How about this? 

"Deployment experience with RADIUS over TLS indicates that it is 

most useful for inter-server communication, such as inter-domain
communication between proxies.  These situations benefit from
the confidentiality and ciphersuite negotiation that can be provided 
by TLS. Since TLS is already widely available within the operating 
systems used by proxies, implementation barriers are low. 

RADIUS over TCP has a similar set of use cases.  Use of TCP as
a transport between a NAS and RADIUS server is a poor fit,
since as noted in [RFC3539], there is likely to be insufficient traffic for 
the congestion window to remain above the minimum value on a
long-term basis.  The result is an increase in packets due to ACKs 
as compared to UDP, without a corresponding set of benefits. 

In server-server communications the traffic levels in both
directions are typically high enough to support a larger
congestion window as well as ACK piggy-backing.  
Through use of an application-layer watchdog as described
in [RFC3539], it is possible to address the objections
to reliable transport described in [RFC2865] Section 2.4. 
However, in these scenarios "bare" TCP does not provide for 
confidentiality or enable negotiation of stronger ciphersuites
than are available in RADIUS. 

As a result of these considerations, use of RADIUS over
TCP SHOULD be restricted to situations where RADIUS over
TLS is employed.  RADIUS over "bare" TCP is NOT RECOMMENDED."

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt; Deployment experience with RADIUS over TLS indicates that is useful<br>&gt; for inter-server communication, such as inter-domain proxying across<br>&gt; the Internet.  The large amounts of traffic, and long-lived<br>&gt; connections are a good fit for TCP transport.  These situations<br>&gt; commonly also require complete data privacy that can be supplied by<br>&gt; TLS.<br>&gt; <br>&gt; The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to<br>&gt; server communication is a bad fit, as there is usually insufficient<br>&gt; traffic to warrant the use of TCP.  Using "bare" TCP for inter-server<br>&gt; communication is a bad fit, as it provides for no data privacy.  The<br>&gt; only valid use-case for "bare" TCP, therefore, is on private, secured<br>&gt; networks where there is simultaneously a large amount of traffic, and<br>&gt; no need for data integrity or privacy.<br><br>
How about this? <br>
<br>
"Deployment experience with RADIUS over TLS indicates that it is <br>
most useful for inter-server communication, such as inter-domain<br>communication between proxies.&nbsp; These situations benefit from<br>the confidentiality and ciphersuite negotiation that can be provided <br>by TLS. Since TLS is already widely available within the operating <br>systems used by proxies, implementation barriers are low. <br><br>RADIUS over TCP has a similar set of use cases.&nbsp; Use of TCP as<br>a transport between a NAS and RADIUS server is a poor fit,<br>since as noted in [RFC3539], there is likely to be insufficient traffic for <br>the congestion window to remain above the minimum value on a<br>long-term basis.&nbsp; The result is an increase in packets due to ACKs <br>as compared to UDP, without a corresponding set of benefits. <br><br>In server-server communications the traffic levels in both<br>directions are typically high enough to support a larger<br>congestion window as well as ACK piggy-backing.&nbsp; <br>Through use of an application-layer watchdog as described<br>in [RFC3539], it is possible to address the objections<br>to reliable transport described in [RFC2865] Section 2.4. <br>However, in these scenarios "bare" TCP does not provide for <br>confidentiality or enable negotiation of stronger ciphersuites<br>than are available in RADIUS. <br><br>As a result of these considerations, use of RADIUS over<br>TCP SHOULD be restricted to situations where RADIUS over<br>TLS is employed.&nbsp; RADIUS over "bare" TCP is NOT RECOMMENDED."<br></body>
</html>
--_ef2723cd-02b5-4019-9e50-c7be4368053d_--

--
to unsubscribe send 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, 17 Sep 2009 15:08:45 +0000
Date: Thu, 17 Sep 2009 17:07:35 +0200
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Jari Arkko <[email-masked]>,  Bernard Aboba <[email-masked]>, "Weber, Gregory D (Greg)" <[email-masked]>,  "David B. Nelson" <[email-masked]>, radext mailing list <[email-masked]>
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt

Romascanu, Dan (Dan) wrote:
> This looks acceptable to me. 
> 
> Alan, do you plan to respin the I-D? 

  Yes.  I can issue one tomorrow.

  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: Thu, 17 Sep 2009 12:10:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 14:08:07 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Weber, Gregory D (Greg)" <[email-masked]>, "David B. Nelson" <[email-masked]>, "radext mailing list" <[email-masked]>

This looks acceptable to me. 

Alan, do you plan to respin the I-D? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, September 17, 2009 1:28 PM
> To: Alan DeKok
> Cc: Bernard Aboba; Romascanu, Dan (Dan); Weber, Gregory D 
> (Greg); David B. Nelson; 'radext mailing list'
> Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
> 
> This resolves my Discuss.
> 
> But do you want to include a strong recommendation to not use 
> these formats, if the plan is to shortly thereafter publish 
> an update of the VSA base format to use 16 bits? Perhaps 
> slightly weaker language would be better here. E.g., "These 
> formats are currently NOT RECOMMENDED, though work is ongoing 
> to possible update the current VSA format."
> 
> Jari
> 
> Alan DeKok wrote:
> > Bernard Aboba wrote:
> >   
> >> As a result of the change, what will Section 2.2 look like?
> >>     
> >
> >   Updated text after the first paragraph below:
> >
> >
> >    Note that the Vendor type field in the recommended VSA 
> format is only
> >    a single octet, like the RADIUS type field.  While this 
> limitation
> >    results in an efficient encoding, there are situations in which a
> >    vendor or SDO will eventually wish to define more than 255
> >    attributes.  Also, an SDO can be comprised of multiple subgroups,
> >    each of whom can desire autonomy over the definition of 
> attributes
> >    within their group.
> >
> >    These desires have led vendors to define the following 
> non-standard
> >    VSA formats:
> >
> >    * Vendor types of 16 bits, followed by an 8 bit length and
> >      then attribute-specific data.
> >
> >    * Vendor types of 32 bits, followed by no length field, and
> >      then attribute-specific data.
> >
> >    * Vendor types of the RFC format, but where some VSAs are
> >      defined as "grouped" or TLV attributes.  These attributes
> >      are then used to carry sub-attributes.
> >
> >    * "Bare" ASCII strings that immediately follow the Vendor-Id,
> >       without using a Vendor type or Vendor length.
> >
> >    All of these formats are NOT RECOMMENDED.  All VSA 
> formats that do
> >    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
> >    RECOMMENDED formats include Vendor types of more than 8 
> bits, Vendor
> >    lengths of less than 8 bits, Vendor lengths of more than 
> 8 bits, and
> >    Vendor-Specific contents that are not in 
> Type-Length-Value format.
> >
> >    Although [RFC2865] does not mandate it, implementations commonly
> >    assume that the Vendor Id can be used as a key to 
> determine the on-
> >    the-wire format of a VSA.  Vendors therefore SHOULD NOT 
> use multiple
> >    formats for VSAs that are associated with a particular 
> Vendor Id.  A
> >    vendor wishing to use multiple VSA formats, SHOULD 
> request one Vendor
> >    Id for each VSA format that they will use.
> >
> >   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/>
> >
> >   
> 
> 

--
to unsubscribe send 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, 17 Sep 2009 10:28:20 +0000
Date: Thu, 17 Sep 2009 13:27:54 +0300
From: Jari Arkko <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "[email-masked]" <[email-masked]>, "Weber, Gregory D (Greg)" <[email-masked]>,  "David B. Nelson" <[email-masked]>, 'radext mailing list' <[email-masked]>
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt

This resolves my Discuss.

But do you want to include a strong recommendation to not use these 
formats, if the plan is to shortly thereafter publish an update of the 
VSA base format to use 16 bits? Perhaps slightly weaker language would 
be better here. E.g., "These formats are currently NOT RECOMMENDED, 
though work is ongoing to possible update the current VSA format."

Jari

Alan DeKok wrote:
> Bernard Aboba wrote:
>   
>> As a result of the change, what will Section 2.2 look like?
>>     
>
>   Updated text after the first paragraph below:
>
>
>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet, like the RADIUS type field.  While this limitation
>    results in an efficient encoding, there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also, an SDO can be comprised of multiple subgroups,
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
>
>    These desires have led vendors to define the following non-standard
>    VSA formats:
>
>    * Vendor types of 16 bits, followed by an 8 bit length and
>      then attribute-specific data.
>
>    * Vendor types of 32 bits, followed by no length field, and
>      then attribute-specific data.
>
>    * Vendor types of the RFC format, but where some VSAs are
>      defined as "grouped" or TLV attributes.  These attributes
>      are then used to carry sub-attributes.
>
>    * "Bare" ASCII strings that immediately follow the Vendor-Id,
>       without using a Vendor type or Vendor length.
>
>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
>    lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
>    Vendor-Specific contents that are not in Type-Length-Value format.
>
>    Although [RFC2865] does not mandate it, implementations commonly
>    assume that the Vendor Id can be used as a key to determine the on-
>    the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
>    formats for VSAs that are associated with a particular Vendor Id.  A
>    vendor wishing to use multiple VSA formats, SHOULD request one Vendor
>    Id for each VSA format that they will use.
>
>   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/>
>
>   

--
to unsubscribe send 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, 17 Sep 2009 10:06:57 +0000
Date: Thu, 17 Sep 2009 12:06:20 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Jari Arkko <[email-masked]>,  "[email-masked]" <[email-masked]>, "Weber, Gregory D (Greg)" <[email-masked]>,  "David B. Nelson" <[email-masked]>, 'radext mailing list' <[email-masked]>
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt

Bernard Aboba wrote:
> As a result of the change, what will Section 2.2 look like?

  Updated text after the first paragraph below:

   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.

   These desires have led vendors to define the following non-standard
   VSA formats:

   * Vendor types of 16 bits, followed by an 8 bit length and
     then attribute-specific data.

   * Vendor types of 32 bits, followed by no length field, and
     then attribute-specific data.

   * Vendor types of the RFC format, but where some VSAs are
     defined as "grouped" or TLV attributes.  These attributes
     are then used to carry sub-attributes.

   * "Bare" ASCII strings that immediately follow the Vendor-Id,
      without using a Vendor type or Vendor length.

   All of these formats are NOT RECOMMENDED.  All VSA formats that do
   not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.

   Although [RFC2865] does not mandate it, implementations commonly
   assume that the Vendor Id can be used as a key to determine the on-
   the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats, SHOULD request one Vendor
   Id for each VSA format that they will use.

  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: Thu, 17 Sep 2009 09:44:23 +0000
Date: Thu, 17 Sep 2009 11:43:26 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item

Bernard Aboba wrote:
> [BA] My impression was that this document (like RADIUS over TLS and
> RADIUS over DTLS) was targeted for Experimental status.

  Fixed.

> Abstract
...
> [BA] It might be worth stating that this specification was developed
> primarily for addressing the transport issues inherent in RADIUS over
> TLS, and that it is not intended for use by itself.   

  That text is also in Section 1.1, but it doesn't hurt to emphasize it
here.

> [BA] Determining when a client or server is down is not automatically
> solved by choice of a reliable transport.

  TCP can provide a positive statement when a connection is down.

> For example, without an application layer watchdog, an application
> relying on TCP would typically need to wait
> until the connection timed out before trying another server.

  Yes.  Or, receiving a FIN when a connection is closed.

>  This is
> the problem identified by RFC 2865, which talks about UDP be used for
> faster failover than would be permitted by TCP without a watchdog. 
> However, failover as envisaged by RFC 2865 does not require deducing
> that a server is "down" based on lack of a reply;  doing so would
> require a much longer waiting interval than implementations typically
> provide.  RADIUS over UDP implementations typically don't care whether
> the server is "down" or not; they only care that it hasn't responded
> after set time interval or number of retries.

  For robust proxying, a number of implementations track server state.
They can implement simple checks such as "no response to any packet in
the last 60 seconds".  They can then mark a server as "down", remove it
from any pool of active servers, and refuse to forward *new* packets to it.

>  However, none of this is
> specified in RFC 2865 (or RFC 5080), so the quality of the failover
> algorithm will vary between implementations.  This I think is the
> more relevant point -- lack of a standardized failover algorithm. 
> Presumably, this document can address that problem.

 Hmm... I'm not so sure.  Failover algorithms are hard to get right.
And I don't think that the TCP document is the best place to discuss
general RADIUS failover.

  Defining a TCP watchdog is OK, but that's just referencing RFC 3539.

  Maybe the text should say instead:

* Connectionless transport.  Neither clients nor servers receive
positive statements that a "connection" is down.  This information has
to be deduced instead from the absence of a reply to a request.

> [BA] I would disagree that the failover problem is necessarily minor; 
> in implementations I'm familiar with, developing a stable and reliable
> failover algorithm was a major pain.

  Agreed.

>  With respect to the reasoning
> behind the development of RADIUS over TCP, is the issue really the need
> for a "different set of tradeoffs", or is the issue the different set of
> needs that manifest themselves in proxy-proxy transport situations?

  Both, I think.  Suggested rewording:

As RADIUS is widely deployed, and has been widely deployed for well
over a decade, these issues have been minor in some use-cases, and
problematic in others.  New systems may be interested in choosing a
different set of trade-offs than those outlined in [RFC2865] Section
2.4.  New systems may also be interested in choosing a more reliable
transport for use-cases such as inter-server proxying.  For those
systems, we define RADIUS over TCP.

> [BA] I think you might say a bit more about the applicability of RADIUS
> over "bare" TCP.  For example, that
> it is only useful in proxy-proxy scenarios where the traffic is
> protected by TLS.  The reasons given might include both transport as
> well as security and interoperability concerns.   For example, we have
> seen interoperability problems result in situations where application
> layer protocols can be transported in multiple ways (e.g. SIP), and
> proxy-proxy scenarios can benefit from stronger/more flexible security,
> as envisaged in RADIUS over TLS. 

  How about this text:

Deployment experience with RADIUS over TLS indicates that is useful
for inter-server communication, such as inter-domain proxying across
the Internet.  The large amounts of traffic, and long-lived
connections are a good fit for TCP transport.  These situations
commonly also require complete data privacy that can be supplied by
TLS.

The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
server communication is a bad fit, as there is usually insufficient
traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
communication is a bad fit, as it provides for no data privacy.  The
only valid use-case for "bare" TCP, therefore, is on private, secured
networks where there is simultaneously a large amount of traffic, and
no need for data integrity or privacy.

  Alan DeKok.

  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: Wed, 16 Sep 2009 17:53:57 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 16 Sep 2009 10:53:40 -0700

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here are my comments:

Category: Proposed Standards

[BA] My impression was that this document (like RADIUS over TLS and RADIUS over DTLS) was targeted for Experimental status. 

Abstract

   The Remote Authentication Dial In User Server (RADIUS) Protocol has
   traditionally used the User Datagram Protocol (UDP) as it's
   underlying transport layer.  This document defines RADIUS over the
   Transmission Control Protocol (TCP).

[BA] It might be worth stating that this specification was developed primarily for addressing the transport issues inherent in RADIUS over TLS, and that it is not intended for use by itself.    

Section 1

      * Connectionless transport.  Neither clients nor servers can
      reliably detect when the other is down.  This information has to
      be deduced instead from the absence of a reply to a request.

[BA] Determining when a client or server is down is not automatically solved by choice of a reliable transport.

For example, without an application layer watchdog, an application relying on TCP would typically need to wait

until the connection timed out before trying another server.  This is the problem identified by RFC 2865, which talks about UDP be used for faster failover than would be permitted by TCP without a watchdog.  However, failover as envisaged by RFC 2865 does not require deducing that a server is "down" based on lack of a reply;  doing so would require a much longer waiting interval than implementations typically provide.  RADIUS over UDP implementations typically don't care whether the server is "down" or not; they only care that it hasn't responded after set time interval or number of retries.  However, none of this is specified in RFC 2865 (or RFC 5080), so the quality of the failover algorithm will vary between implementations.  This I think is the

more relevant point -- lack of a standardized failover algorithm.  Presumably, this document can address that problem. 

   As RADIUS is widely deployed, and has been widely deployed for well
   over a decade, these issues are relatively minor.  However, new
   systems may be interested in choosing a different set of trade-offs
   than those outlined in [RFC2865] Section 2.4.  For those systems, we
   define RADIUS over TCP.

[BA] I would disagree that the failover problem is necessarily minor;  in implementations I'm familiar with, developing a stable and reliable failover algorithm was a major pain.  With respect to the reasoning behind the development of RADIUS over TCP, is the issue really the need for a "different set of tradeoffs", or is the issue the different set of needs that manifest themselves in proxy-proxy transport situations?  As described in RFC 3539, NAS-proxy scenarios do not really benefit from reliable transport because the connection would be likely to run with the minimum congestion window most of the time.  As a result, using reliable transport just generates a lot of ACK traffic without making use of the congestion control/window management benefits of TCP. This is not necessarily the case for proxy-proxy transport where the volume may be quite a bit higher.  

Section 1.1

   The intent of this document is to address transport issues related to
   RadSec [RADSEC].  The use of "bare" TCP transport is NOT RECOMMENDED,
   as there has been little implementational or operational experience
   with it.  Additionally, [RFC2865] Section 2.4 contains a list of
   reasons why UDP was originally chosen as the transport protocol for
   RADIUS.  UDP SHOULD be used as transport protocol in all cases where
   the rationale given in [RFC2865] Section 2.4 applies.

[BA] I think you might say a bit more about the applicability of RADIUS over "bare" TCP.  For example, that

it is only useful in proxy-proxy scenarios where the traffic is protected by TLS.  The reasons given might include both transport as well as security and interoperability concerns.   For example, we have seen interoperability problems result in situations where application layer protocols can be transported in multiple ways (e.g. SIP), and proxy-proxy scenarios can benefit from stronger/more flexible security, as envisaged in RADIUS over TLS.  

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

Here are my comments:<br>
&nbsp;<br>
Category: Proposed Standards<br>
&nbsp;<br>
[BA] My impression was that this&nbsp;document (like RADIUS over TLS and RADIUS over DTLS) was targeted for Experimental status. <br>
&nbsp;<br>
Abstract<br><br>&nbsp;&nbsp; The Remote Authentication Dial In User Server (RADIUS) Protocol has<br>&nbsp;&nbsp; traditionally used the User Datagram Protocol (UDP) as it's<br>&nbsp;&nbsp; underlying transport layer.&nbsp; This document defines RADIUS over the<br>&nbsp;&nbsp; Transmission Control Protocol (TCP).<br><br>
[BA] It might be worth stating that this specification was developed primarily for addressing the transport issues inherent in RADIUS over TLS, and that it is not intended for use by itself.&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Section 1<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Connectionless transport.&nbsp; Neither clients nor servers can<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reliably detect when the other is down.&nbsp; This information has to<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be deduced instead from the absence of a reply to a request.<br><br>
[BA] Determining when a client or server is down is not automatically solved by choice of a reliable transport.<br>
For example, without an application layer watchdog, an application relying on TCP would typically need to wait<br>
until the connection timed out before trying another server.&nbsp; This is the problem identified by RFC 2865, which&nbsp;talks about UDP be used&nbsp;for faster&nbsp;failover than would be permitted by&nbsp;TCP without a watchdog.&nbsp; However,&nbsp;failover as envisaged by RFC 2865 does not require deducing that a&nbsp;server is "down" based on lack of a reply;&nbsp;&nbsp;doing so would require a much longer waiting interval than implementations typically provide.&nbsp; RADIUS over UDP implementations typically don't care whether the server is "down" or not; they only care that it hasn't responded after set time interval or number of retries.&nbsp;&nbsp;However, none of this is specified in RFC 2865 (or RFC 5080), so&nbsp;the quality of the failover algorithm will vary between implementations.&nbsp; This I think is the<br>
more relevant point -- lack of a standardized failover algorithm.&nbsp; Presumably, this document can address that problem. <br>
&nbsp;<br>
&nbsp;&nbsp; As RADIUS is widely deployed, and has been widely deployed for well<br>&nbsp;&nbsp; over a decade, these issues are relatively minor.&nbsp; However, new<br>&nbsp;&nbsp; systems may be interested in choosing a different set of trade-offs<br>&nbsp;&nbsp; than those outlined in <a href="http://tools.ietf.org/html/rfc2865#section-2.4"><font color="#0066cc">[RFC2865] Section&nbsp;2.4</font></a>.&nbsp; For those systems, we<br>&nbsp;&nbsp; define RADIUS over TCP.<br><br>
[BA] I would disagree that the failover problem is necessarily minor;&nbsp; in implementations I'm familiar with, developing a stable and reliable failover algorithm was a major pain.&nbsp; With respect to the reasoning behind the development of RADIUS over TCP, is the issue really the need for a "different set of tradeoffs", or is the issue the&nbsp;different set of needs that&nbsp;manifest themselves in proxy-proxy transport situations?&nbsp;&nbsp;As described in RFC 3539, NAS-proxy&nbsp;scenarios do not really benefit from reliable transport because the connection&nbsp;would be likely to&nbsp;run with&nbsp;the minimum congestion window most of the time.&nbsp; As a result, using reliable transport just generates a lot of ACK traffic without making use of the congestion control/window management benefits of TCP. This is not necessarily the case for proxy-proxy transport where the volume may be quite a bit higher.&nbsp; <br>
&nbsp;<br>
Section 1.1<br>
&nbsp;<br>
&nbsp;&nbsp; The intent of this document is to address transport issues related to<br>&nbsp;&nbsp; RadSec [<a title="&quot;TLS encryption for RADIUS over TCP (RadSec)&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-tcp-transport-03#ref-RADSEC"><font color="#0066cc">RADSEC</font></a>].&nbsp; The use of "bare" TCP transport is NOT RECOMMENDED,<br>&nbsp;&nbsp; as there has been little implementational or operational experience<br>&nbsp;&nbsp; with it.&nbsp; Additionally, <a href="http://tools.ietf.org/html/rfc2865#section-2.4"><font color="#0066cc">[RFC2865] Section&nbsp;2.4</font></a> contains a list of<br>&nbsp;&nbsp; reasons why UDP was originally chosen as the transport protocol for<br>&nbsp;&nbsp; RADIUS.&nbsp; UDP SHOULD be used as transport protocol in all cases where<br>&nbsp;&nbsp; the rationale given in <a href="http://tools.ietf.org/html/rfc2865#section-2.4"><font color="#0066cc">[RFC2865] Section&nbsp;2.4</font></a> applies.<br><br>
[BA] I think you might say a bit more about the&nbsp;applicability of&nbsp;RADIUS over "bare" TCP.&nbsp; For example, that<br>
it is only useful in proxy-proxy scenarios where the traffic is protected by TLS.&nbsp; The reasons given might include both transport as well as security and interoperability concerns.&nbsp;&nbsp;&nbsp;For example, we have seen interoperability problems result in situations where application layer protocols can be transported in multiple ways (e.g. SIP), and proxy-proxy scenarios can benefit from stronger/more flexible security, as envisaged in RADIUS over TLS.&nbsp; <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br></body>
</html>
--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_--

--
to unsubscribe send 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, 16 Sep 2009 17:52:42 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Wed, 16 Sep 2009 10:52:21 -0700

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT WG will be having a Virtual Interim Meeting on Tuesday, October 13, 2009 from 8:00 AM - 10:00 AM PDT.  

Details on the agenda and conference calling parameters for the meeting will be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}</style>The RADEXT WG will be having a Virtual Interim Meeting on Tuesday, October 13, 2009 from 8:00 AM - 10:00 AM PDT.&nbsp; <br><br>Details on the agenda and conference calling parameters for the meeting will be available here:<br>http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt<br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_--

--
to unsubscribe send 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, 16 Sep 2009 17:52:15 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Wed, 16 Sep 2009 10:51:39 -0700

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Tuesday, October 13, 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)

8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status 

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana</style>RADEXT WG Virtual Interim Agenda<br><pre><br>Chairs: Bernard Aboba &lt;[email-masked]&gt;<br>David Nelson &lt;[email-masked]&gt;<br><br>Tuesday, October 13, 2009<br>8 AM - 10 AM PDT (11:00 - 13:00 EDT)<br><br><br>8:00 AM - 8:20 AM  Preliminaries<br>   Jabber scribe<br>   Document Status <br><br>Documents completing IETF Last Call (20 minutes)<br><br>8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-design<br><br>Documents Completing WG Last Call (20 minutes)<br><br>8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-radsec<br><br>8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><br>9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-tcp-transport<br><br>WG Work Items (20 minutes)<br><br>9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<br><br>9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-dtls<br><br><br></pre><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_fd1f39e7-4177-487b-9354-1fa6eb06b008_--

--
to unsubscribe send 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, 16 Sep 2009 16:25:47 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 09:24:54 -0700

--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

> That text looks good to me.

--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
+1<br><br>&gt; That text looks good to me.<br><br><br></body>
</html>
--_46b58ef5-5872-4128-808f-149a7751ec96_--

--
to unsubscribe send 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, 16 Sep 2009 15:19:04 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 11:18:19 -0400

Alan DeKok writes...

>   See the last sentence you quoted:
> 
>    The specification SHOULD
>    NOT define or describe the structure, as discussed above in Section
>    2.1.3.
> 
>   If it's an opaque type, then the format shouldn't be described in a
> RADIUS document.

Right.  Hopefully future authors will take that to heart.  :-)

>   I believe so.  How about breaking those definitions out into a new
> section:
> 
> A.1.2. Transport of Authentication and Security Data
> 
>    Does the data provide authentication and/or security capabilities, as
>    outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
>    format RADIUS attribute.  It SHOULD NOT be encapsulated in a
>    [RFC2865] format RADIUS VSA.
> 
>       * Complex data types that carry authentication methods which
>         RADIUS servers are expected to parse and verify as part of
>         an authentication process.
> 
>       * Complex data types that carry security information intended
>         to increase the security of the RADIUS protocol itself.
> 
>    Any data type carrying authentication and/or security data that is
>    not meant to be parsed by a RADIUS server is an "opaque data type",
>    as defined below.

That text looks good to me.

--
to unsubscribe send 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, 16 Sep 2009 13:27:28 +0000
Date: Wed, 16 Sep 2009 15:26:39 +0200
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: [email-masked]
Subject: Re: Issue 313:  Security Exemption

Dave Nelson wrote:
>>     * define a complex data type
>>     * that the RADIUS server and/or client will not treat as opaque data
>>       (see Section A.1.3)
> 
> Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

  Yes.

> What's the status of an attribute if the author claims that it can be opaque
> to a RADIUS server implementation, but the format of the data payload
> contained in the attribute is not defined in any other document, but rather
> defined, in standard RADIUS attribute fashion, within the RADIUS extension
> document itself?  Does that qualify for meeting the opaqueness test of
> A.1.2?

  See the last sentence you quoted:

   The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

  If it's an opaque type, then the format shouldn't be described in a
RADIUS document.

>>   If the RADIUS server has to parse it, then complex attributes are
>> allowed for authentication and security...
> 
> I want to further nail down these two words: authentication, security.
> 
> Does authentication mean that the attribute is used to implement a RADIUS
> Authentication Method?
> 
> Does security means that the attribute is used to provide message integrity
> or message confidentiality for the RADIUS datagram itself?
> 
> Those extended definitions match what I think is the intent.

  I believe so.  How about breaking those definitions out into a new
section:

A.1.2. Transport of Authentication and Security Data

   Does the data provide authentication and/or security capabilities, as
   outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
   format RADIUS attribute.  It SHOULD NOT be encapsulated in a
   [RFC2865] format RADIUS VSA.

      * Complex data types that carry authentication methods which
        RADIUS servers are expected to parse and verify as part of
        an authentication process.

      * Complex data types that carry security information intended
        to increase the security of the RADIUS protocol itself.

   Any data type carrying authentication and/or security data that is
   not meant to be parsed by a RADIUS server is an "opaque data type",
   as defined below.

> On the other hand, security could mean all sorts of things.  It could be a
> key-wrap attribute for a key to be used in the NAS or the attached
> end-point.

  e.g. the MS-MPPE-keys... but those could fit into the standard RADIUS
data model with a bit of tweaking.

> I'd really like to see this definitional issue tightened up before the next
> draft version is issued.

  Suggested text is above.

  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: Wed, 16 Sep 2009 12:29:15 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:28:50 -0400

Alan DeKok wrote...
> 
>   ?
> 
>    Does the attribute:
> 
>     * define a complex data type
>     * that the RADIUS server and/or client will not treat as opaque data
>       (see Section A.1.3)

Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

A.1.2. Opaque data types

   Does the attribute encapsulate an existing data structure defined
   outside of the RADIUS specifications?  Can the attribute be treated
   as opaque data by RADIUS servers (including proxies?)  If both
   questions can be answered affirmatively, a complex structure MAY be
   used in a RADIUS specification.

   The specification of the attribute SHOULD define the encapsulating
   attribute to be of type String.  The specification SHOULD refer to an
   external document defining the structure.  The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

What's the status of an attribute if the author claims that it can be opaque
to a RADIUS server implementation, but the format of the data payload
contained in the attribute is not defined in any other document, but rather
defined, in standard RADIUS attribute fashion, within the RADIUS extension
document itself?  Does that qualify for meeting the opaqueness test of
A.1.2?
 
>   If the RADIUS server can treat it as opaque data, then it falls under
> the purview of A.1.3.  It is permitted, independent of it being used for
> authentication, security, or anything else.
> 
>   If the RADIUS server has to parse it, then complex attributes are
> allowed for authentication and security...

I want to further nail down these two words: authentication, security.

Does authentication mean that the attribute is used to implement a RADIUS
Authentication Method?

Does security means that the attribute is used to provide message integrity
or message confidentiality for the RADIUS datagram itself?

Those extended definitions match what I think is the intent.

On the other hand, security could mean all sorts of things.  It could be a
key-wrap attribute for a key to be used in the NAS or the attached
end-point.  It could be a security policy such as access control information
or a mandatory cipher-suite.  I could go on.  Lots and lots of things fall
under the moniker of security.

I'd really like to see this definitional issue tightened up before the next
draft version is issued.

--
to unsubscribe send 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, 16 Sep 2009 12:15:13 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:13:54 -0400

Bernard wrote...

> > If the RADIUS server has to parse it, then complex attributes are
> > allowed for authentication and security...
>
> I think the question is why the exemption should be so broad.  The
> security and authentication attributes described in Appendix B required
> computation.  That is the RADIUS server had to add code in order to
> compare the authentication result presented by the RADIUS client with the
> result it calculated based on its own data. 
>
> However, if the RADIUS server doesn't have to do any computation (e.g.
> if it is just sending security or authentication-related data to the
> RADIUS client), then there is no intrinsic reason why RADIUS server
> code needs to change.  In that case, why should the exemption apply?

I don't think I ever saw an answer to this on the list.  Could we close out
this discussion, and perhaps craft some revised text, before the next draft
version is submitted?

--
to unsubscribe send 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, 13 Sep 2009 18:25:25 +0000
Date: Sun, 13 Sep 2009 20:24:08 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RADEXT Virtual Interim Agenda - Take One

Bernard Aboba wrote:
> RADEXT WG Virtual Interim Agenda

  On a related note, how many people plan on being at the next IETF?

  I'm not sure yet if I will be able to make 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/>

Delivery-date: Sat, 12 Sep 2009 20:14:18 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Sat, 12 Sep 2009 13:13:48 -0700

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Tuesday, October 13, 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)

8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status 

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<pre>RADEXT WG Virtual Interim Agenda<br><br>Chairs: Bernard Aboba &lt;[email-masked]&gt;<br>David Nelson &lt;[email-masked]&gt;<br><br>Tuesday, October 13, 2009<br>8 AM - 10 AM PDT (11:00 - 13:00 EDT)<br><br><br>8:00 AM - 8:20 AM  Preliminaries<br>   Jabber scribe<br>   Document Status <br><br>Documents completing IETF Last Call (20 minutes)<br><br>8:20 AM - 8:40 AM Design Guidelines document, Alan DeKok (20  minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-design<br><br>Documents Completing WG Last Call (20 minutes)<br><br>8:40 AM - 8:50 AM RADSEC, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-radsec<br><br>8:50 AM - 9:00 AM Status-Server document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><br>9:00 AM - 9:10 AM RADIUS over TCP document, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-tcp-transport<br><br>WG Work Items (20 minutes)<br><br>9:10 AM - 9:20 AM NAI-based Peer Discovery, Stefan Winter (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<br><br>9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-dtls<br><br><br></pre><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_eec3214d-b35d-4623-92f3-b729d44cd4f1_--

--
to unsubscribe send 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, 12 Sep 2009 19:55:08 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Sat, 12 Sep 2009 12:53:55 -0700

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT WG will be having a Virtual Interim Meeting on Tuesday, October 13, 2009 from 8:00 AM - 10:00 AM PDT.  

Details on the agenda and conference calling parameters for the meeting will be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The RADEXT WG will be having a Virtual Interim Meeting on Tuesday, October 13, 2009 from 8:00 AM - 10:00 AM PDT.&nbsp; <br><br>Details on the agenda and conference calling parameters for the meeting will be available here:<br>http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt<br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_eef42904-7302-4c5b-9a39-40ee19fd8f02_--

--
to unsubscribe send 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, 10 Sep 2009 14:16:33 +0000
Date: Thu, 10 Sep 2009 16:15:38 +0200
From: Alan DeKok <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Alper Yegin <[email-masked]>,  "'Romascanu, Dan \(Dan\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: Re: [Technical Errata Reported] RFC4282 (1848)

Jari Arkko wrote:
> Section 1.2 boilerplate is not according to RFC 2119.

  Fixed.

> grammer => grammar

  Fixed.

>> o Section 2.1 did not contain ABNF for the UTF-8 form of the  
>>             realm. This makes it impossible to create an
>> inter-operable               internationalized version of the realm
> 
> But the realm was not specified to carry UTF-8. As the RFC said later:
...
> I realize that there may be other reasons -- such as compatibility with
> EAP RFCs that demands plain UTF-8 should be used. However, the argument
> above does not seem correct.

  The later text discusses this, and could be merged:

o The requirement in Section 2.1 that realms are ASCII conflicts
  with the Extensible Authentication Protocol (EAP) and RADIUS, which
  are both 8-bit clean, and which both recommend the use of UTF-8 for
  identities.

>> o Section 2.5 required mappings that are language-specific,  
>>             and which are nearly impossible to perform correctly
>> without               information about that language.
> 
> I guess this means Section 2.4 of RFC 4282, right?

  Yes.

> Also, the mappings required in that section are to be done by the end
> systems where the user types in the strings. Such end systems can be
> aware of what character set and language the user employs. I agree that
> none of the intermediate systems could have any idea about that, but
> AFAICT that was not required by the RFC.

  The suggestion was for proxies to perform normalized comparisons,
which requires the mappings.

  The update suggests (essentially) using "strcmp" for comparisons.

  That could say instead:

o Section 2.4 required mappings that are language-specific,
  and which are nearly impossible for intermediate nodes to perform
  correctly without information about that language.

>>  normalization form NFC for NAIs is REQUIRED.
> Expand NFC

  Done.

>> The grammar for       the username is based on [RFC0821], and the
>> grammar for the realm is        the user and realm portion is based on
>> a combination of the "nai"       an updated version of
>> [RFC1035].        defined in [RFC4282] Section 2.1, and the
>> "utf8-addr-spec" defined in               [RFC5335] Section 4.4.
> I was confused by this statement. Do you mean that you normatively refer
> 4282 for these definitions or that this is how you arrived at the ABNF?

  It means how I arrived at the ABNF.

> I think you should just say "this is the ABNF" and if there's any
> rationale that needs to be said, add it to Section 1.4.

  Ok.  It looked awkward to add it to 1.4, so I added it to the appendix.

>> .fi
> Nroff problem...

  Fixed.

>> in question. Therefore, the username portion SHOULD be treated as
> 
> Since you changed the ABNF names, this probably should now be
> utf8-username to be exact what you mean by the username portion.

  Fixed.

>> In order to ensure a canonical representation
> 
> I would like to understand this better. 4282 provided canonicalization
> in order to make sure that when you look up a username db lookups and
> routing table comparisons work. Does the bis have the same property, and
> how so?

  We can say:

The form suggested in [RFC4282] depended on
intermediate nodes performing canonicalizations based on insufficient
information, which meant that the form was not canonical.  This
document instead suggests (Section 2.10) that the realm owner provide
a canonical form of the realm, and that all intermediate nodes use
that form without modification.

  This means that there is only one canonical form: that supplied by the
realm owner.

>>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>>    systems to perform NAI comparisons, matching, and AAA routing based
>>    on the NAI as it is received.  This requirement provides a canonical
>>    representation, ensures that intermediate systems such as AAA proxies
>>    do not need to perform translations, and can be expected to work
>>    through systems that are unaware of international character sets.
> 
> I though that this was the case already with RFC 4282, but maybe I'm
> missing something.

  See the above comment.  The *intent* in 4282 was to provide a
canonical representation.  Unfortunately, it cannot be used to provide that.

>> For example, much of the common realm routing can be done on the  
>>             "utf8-realm" portion of NAI, through simple checks for
>> equality.
> 
> I thought that suffix match was also a possibility in some systems.

  A *partial* suffix match?  (e.g. foo.example.com matches example.com)

  That's possible, but fairly rare.

>> There are, however, a number of problems with this approach. A AAA  
>>             proxy may not have sufficient information in order to
>> perform the               ToAscii conversion properly. ...

> And here's the tradeoff for using UTF-8 as opposed to IDN unaware name
> slots. I was trying to think about situations where the DNS lookups are
> needed and whether they'd form a problem. Can you name a few of the
> situations where DNS name lookups from NAIs are actually used today?

  Diameter.  RadSec (RADIUS over SSL over TCP), which is being
standardized right now.

  It's pretty rare, which means we should get it right before we have
wide-spread deployments.

  I'm not aware of any scenario where AAA servers would use arbitrary
strings supplied by the user to do DNS lookups, or why anyone would
think that this is a good idea.

  It would be MUCH better to have a AAA routing protocol, where "home"
servers could propagate realm / punycode data to proxies.

  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: Thu, 10 Sep 2009 09:08:48 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>
Cc: <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Harald Tveit Alvestrand" <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Thu, 10 Sep 2009 11:07:18 +0200

Jari Arkko [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > I thought about writing a long response to this, referencing RFCs
> 3454 &
> > 4013 and the Unicode 3.2 standard but in the end decided that the use
> of
> > logic and analysis would be a total waste of time.  So I'll just say
> that
> > this Errata makes no sense at all & let it go at that.  To understand
> why
> > it's nonsense, you'll have to do your own research.
> >
> >
> 
> Humor me

If you insist...

> Apparently I don't understand i18n as well as the rest of you do :-)

I absolutely not an expert on internationalization (though I confess to
having conversed occasionally with Paul Hoffman & Harald Alvestrand, who are
veritable founts of knowledge on the subject -- hopefully if I get any of
this wrong one of them can save us from my ignorance): the last work I did
on it was for L2TPv3 more than 4 years ago.  Fortunately, however, no such
expertise is really needed, aside from the abilities to read and reason.
The reference in the original text to which the erratum refers is to section
2.5 of RFC 4013, but that just points to Appendix A.1 of RFC 3454.  Appendix
A.1 is just a list of the unassigned code points in Unicode 3.2.  There is
no mechanism specified in 3454 for assigning code points (via IANA, for
example); that's because code points are assigned in the Unicode standard.
That should be enough: the list of unassigned code points is in an RFC
which, by definition, will never change.  If, however, one possessed a
little bit of knowledge about Unicode (say, from spending 20-30 minutes
looking around http://www.unicode.org) one could discover that the assigned
and unassigned code points are part of the Unicode repertoire for a given
major or minor version of the standard.  This means that section A.1 of RFC
3454 defines forever the set of unassigned code points: unassigned code
points may be assigned but not in v3.2.  I hope it's clear from this
discussion that talking about "unassigned code points" w/o reference to a
stringprep profile or Unicode version is meaningless.  The "old text" was
correct and precise, including a stable reference to a well-defined set of
code points; the proposed replacement text is, quite literally, nonsense.

> Jari

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

Delivery-date: Wed, 09 Sep 2009 17:45:35 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Wed, 9 Sep 2009 19:44:07 +0200

I thought about writing a long response to this, referencing RFCs 3454 &
4013 and the Unicode 3.2 standard but in the end decided that the use of
logic and analysis would be a total waste of time.  So I'll just say that
this Errata makes no sense at all & let it go at that.  To understand why
it's nonsense, you'll have to do your own research.

> The following errata report has been submitted for RFC4282,
> "The Network Access Identifier".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfcB82&eid50
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <[email-masked]>
> 
> Section: 2.4
> 
> Original Text
> -------------
>    o  Unassigned code points are specified in Section 2.5 of [RFC4013].
>       The use of unassigned code points is prohibited.
> 
> Corrected Text
> --------------
>   o Unassigned code points MUST be ignored
> 
> Notes
> -----
> Unassigned code points sometimes go through a process called
> "assignment".  This means that they suddenly become valid.
> 
> Implementations that forbid unassigned code points will not be updated
> when the standards change to assign them.  Therefore, they should
> ignore unassigned code points.
> 
> Happily, this is what all implementations do.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> --
> to unsubscribe send 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, 09 Sep 2009 17:02:17 +0000
Date: Wed, 09 Sep 2009 20:01:53 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
CC: Alper Yegin <[email-masked]>,  'Glen Zorn' <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked],  [email-masked]
Subject: Re: [Technical Errata Reported] RFC4282 (1848)

Thanks again for writing this up.

Some initial comments:

Overall I liked it, but there are of course of number of things to 
discuss...

Section 1.2 boilerplate is not according to RFC 2119.

grammer => grammar

> o Section 2.1 did not contain ABNF for the UTF-8 form of the   
>             realm. This makes it impossible to create an 
> inter-operable   
>             internationalized version of the realm

But the realm was not specified to carry UTF-8. As the RFC said later:

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

I realize that there may be other reasons -- such as compatibility with 
EAP RFCs that demands plain UTF-8 should be used. However, the argument 
above does not seem correct.

> o Section 2.5 required mappings that are language-specific,   
>             and which are nearly impossible to perform correctly 
> without   
>             information about that language.

I guess this means Section 2.4 of RFC 4282, right?

Also, the mappings required in that section are to be done by the end 
systems where the user types in the strings. Such end systems can be 
aware of what character set and language the user employs. I agree that 
none of the intermediate systems could have any idea about that, but 
AFAICT that was not required by the RFC.

>  normalization form NFC for NAIs is REQUIRED.
Expand NFC

> The grammar for   
>     the username is based on [RFC0821], and the grammar for the realm 
> is        the user and realm portion is based on a combination of the 
> "nai"   
>     an updated version of [RFC1035].        defined in [RFC4282] 
> Section 2.1, and the "utf8-addr-spec" defined in   
>             [RFC5335] Section 4.4.
I was confused by this statement. Do you mean that you normatively refer 
4282 for these definitions or that this is how you arrived at the ABNF? 
I think you should just say "this is the ABNF" and if there's any 
rationale that needs to be said, add it to Section 1.4.

> .fi

Nroff problem...

> in question. Therefore, the username portion SHOULD be treated as

Since you changed the ABNF names, this probably should now be 
utf8-username to be exact what you mean by the username portion.

> In order to ensure a canonical representation

I would like to understand this better. 4282 provided canonicalization 
in order to make sure that when you look up a username db lookups and 
routing table comparisons work. Does the bis have the same property, and 
how so?

>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>    systems to perform NAI comparisons, matching, and AAA routing based
>    on the NAI as it is received.  This requirement provides a canonical
>    representation, ensures that intermediate systems such as AAA proxies
>    do not need to perform translations, and can be expected to work
>    through systems that are unaware of international character sets.

I though that this was the case already with RFC 4282, but maybe I'm 
missing something.

> For example, much of the common realm routing can be done on the   
>             "utf8-realm" portion of NAI, through simple checks for 
> equality.

I thought that suffix match was also a possibility in some systems.

> 2.7. Routing inside of AAA Systems
Good stuff.

> There are, however, a number of problems with this approach. A AAA   
>             proxy may not have sufficient information in order to 
> perform the   
>             ToAscii conversion properly. We therefore RECOMMEND that 
> only the   
>             owner of the realm perform the ToAscii conversion. We 
> RECOMMEND that   
>             the owner of the realm pre-provision to all proxies the 
> "utf8-realm"   
>             portion of the NAI, along with the canonical form returned 
> by the   
>             ToAscii function. This canonical form can then be used in 
> the   
>             logical AAA routing table discussed above, in order to 
> perform DNS   
>             lookups

And here's the tradeoff for using UTF-8 as opposed to IDN unaware name 
slots. I was trying to think about situations where the DNS lookups are 
needed and whether they'd form a problem. Can you name a few of the 
situations where DNS name lookups from NAIs are actually used today?

> 2.10.1. Historical Practices
I'm personally not very fond of the decoration practices, but they do 
exist. I think we need a discussion before those can be removed from the 
RFC.

Jari

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

Delivery-date: Wed, 09 Sep 2009 16:19:41 +0000
Date: Wed, 09 Sep 2009 19:18:44 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
CC: Glen Zorn <[email-masked]>,  "'Romascanu, Dan \(Dan\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: Re: [Technical Errata Reported] RFC4282 (1848)

Excellent -- I will review this. For the benefit of others, here's a diff:

http://tools.ietf.org/rfcdiff?url1=rfc4282.txt&url2=draft-dekok-radext-nai-00.txt

(and to the original RFC: 
http://tools.ietf.org/rfcdiff?url1=rfc2486.txt&url2=draft-dekok-radext-nai-00.txt)

Jari

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

Delivery-date: Wed, 09 Sep 2009 14:02:47 +0000
From: "Alper Yegin" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>, "'Jari Arkko'" <[email-masked]>
Cc: <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 17:01:30 +0300

> You're absolutely right; I was thinking of RFC 2486, which it obsolete.
> The
> point remains the same, however: changes to 4282 don't just effect
> RADIUS,
> but Diameter, possibly EAP and 

+ Mobile IP family of protocols....

> a number of standards published by other
> SDOs.

Indeed.

What is the take on backward compatibility?

Alper

> 
> >
> > In any case, I would suggest we stop talking about process or other
> non
> > essential stuff. If the 4282 i18n text is not correct, is there some
> > other text that would work, Alan?
> >
> > Jari
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Wed, 09 Sep 2009 13:52:23 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>
Cc: <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:51:26 +0200

Jari Arkko [mailto:[email-masked]] writes:

> Glen,
> 
> > Why not?  My understanding is that accepted technical errata are
> generally
> > saved up & incorporated in a new RFC.  Is that incorrect?  If not,
> why isn't
> > that the way to deal with this particular case?
> >
> 
> Erratas are for correcting small problems. If you have to rewrite large
> parts, that requires significant effort, review, and a proper new
> document.
> 
> > Since 4282 wasn't the product of either the radext or radius WGs,
> what makes
> > radext the right place to do it?  I'd suggest a new WG, with Alan
> DeKok as a
> > Chair.
> >
> 4282 was a product of the RADEXT WG.

You're absolutely right; I was thinking of RFC 2486, which it obsolete.  The
point remains the same, however: changes to 4282 don't just effect RADIUS,
but Diameter, possibly EAP and a number of standards published by other
SDOs.

> 
> In any case, I would suggest we stop talking about process or other non
> essential stuff. If the 4282 i18n text is not correct, is there some
> other text that would work, Alan?
> 
> Jari

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

Delivery-date: Wed, 09 Sep 2009 13:25:53 +0000
Date: Wed, 09 Sep 2009 16:25:40 +0300
From: Jari Arkko <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: [email-masked], "'Romascanu, Dan \(Dan\)'" <[email-masked]>,  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: Re: [Technical Errata Reported] RFC4282 (1848)

Glen,

> Why not?  My understanding is that accepted technical errata are generally
> saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
> that the way to deal with this particular case?
>   

Erratas are for correcting small problems. If you have to rewrite large 
parts, that requires significant effort, review, and a proper new document.

> Since 4282 wasn't the product of either the radext or radius WGs, what makes
> radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
> Chair.
>   
4282 was a product of the RADEXT WG.

In any case, I would suggest we stop talking about process or other non 
essential stuff. If the 4282 i18n text is not correct, is there some 
other text that would work, Alan?

Jari

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

Delivery-date: Wed, 09 Sep 2009 13:23:54 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:22:56 +0200

Alan T DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > I count 8 sentences (including the one reproduced from the RFC), not
> 20.
> 
>   Please check your inbox.  There were other errata filed at the same
> time, with additional explanatory text.

I didn't respond to those.  How are they relevant?

> 
> > One of those sentences appears to be irrelevant hyperbole ("Much of
> RFC 4282
> > is simply wrong.") & another is incomprehensible (what does
> "Normalization
> > can be done only when both the local and character set information is
> > included with the text." mean?  Did you mean "locale"?  Why should we
> have
> > to guess?).  Based upon this evidence, I have no choice but to
> conclude that
> > you are absolutely right: RFC 4282 should be trashed immediately
> (apparently
> > the same conclusion reached by the IESG, based upon the same
> evidence).
> 
>   As I said, please check the RADEXT archives for longer discussions
> about this issue.  That discussion includes comments from other people
> explaining what is wrong with 4282.

Alan, you filed an Errata with the RFC Editor.  Do you expect them to search
the radext archives?

> 
>   Maybe one of those people can talk to you without you claiming that
> they have a god complex.  I know I can't.

For DeKok's sake, quit your whining! ;-)

>   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: Wed, 09 Sep 2009 13:01:03 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>, <[email-masked]>
Cc: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:59:57 +0200

Jari Arkko [mailto:[email-masked]] writes:

> Alan,
> 
> >   It would be good to note at least that the document should be
> largely
> > ignored.  Errata may be a good way to do this.
> >
> 
> I do not believe errata is the right way to do this. 

Why not?  My understanding is that accepted technical errata are generally
saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
that the way to deal with this particular case?

> Furthermore, 4282
> contains more updates than the i18n parts.
> 
> >   There was some discussion last year about working on an update to
> > 4282.  There didn't seem to be much interest, unfortunately.  Maybe
> if
> > we can get the 4-5 pending RADEXT documents out of the way, there may
> be
> > interest in working on updates to 4282.
> >
> 
> That is the best way, IMO. 

Since 4282 wasn't the product of either the radext or radius WGs, what makes
radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
Chair.

> We also need to analyze the problem and
> possible solutions in detail. I confess that I have not looked at the
> issues, so I can offer no comment on them yet.
> 
> Jari

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

Delivery-date: Wed, 09 Sep 2009 12:55:41 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:54:18 +0200

Alan T DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > "it's wrong" hardly qualifies as "pointing out the problems".  OTOH,
> this
> > message (was it so hard?) may.
> 
>   The errata I filed had explanations as to what was wrong, why it was
> wrong, and suggested replacement text.
> 
>   You picked *one* sentence out of 20, ignored the rest, ignored the
> previous mailing list discussion, and then claimed (essentially) that I
> had no justification for seeing problems with 4282.
> 
>   Could you please read my messages before attacking me?

Terribly unfair of me.  To redress this wrong, I have reproduced the erratum
in question in full below:

Errata ID: 1848

Status: Reported
Type: Technical

Reported By: Alan DeKok
Date Reported: 2009-09-08

Section 2.4 says: 

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

It should say:

  o Normalization is, in general, a bad idea.
Notes:

Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set
information is included with the text. And that information is not included
with the username or realm.

In addition, not all systems will treat "User" the same as "user". The
decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be
performed on
any system other than the final one that performs user authentication. 

I count 8 sentences (including the one reproduced from the RFC), not 20.
One of those sentences appears to be irrelevant hyperbole ("Much of RFC 4282
is simply wrong.") & another is incomprehensible (what does "Normalization
can be done only when both the local and character set information is
included with the text." mean?  Did you mean "locale"?  Why should we have
to guess?).  Based upon this evidence, I have no choice but to conclude that
you are absolutely right: RFC 4282 should be trashed immediately (apparently
the same conclusion reached by the IESG, based upon the same evidence).

>   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: Wed, 09 Sep 2009 10:25:46 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 12:24:15 +0200

Alan T DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Not that I want to question (God forbid!) the godlike opinion of Alan
> DeKok,
> > but could we have just a smidgeon of justification for that statement
> before
> > tossing RFC 4282?
> 
>   Perhaps you would appreciate my comments more if I noted that:
> 
> a) the i18n work in 4282 has been deprecated, found to be faulty, or
>    replaced, by later i18n documents
> 
> b) nearly all of the rest of the recommendations in 4282 have been
>    ignored (and not implemented) by all of the AAA vendors
> 
> c) I was not involved in any of the i18n work that negated the
>    recommendations of 4282
> 
> d) no major AAA vendor has ever asked for my opinion on how to
>    implement 4282 in their product.
> 
> 
>   Don't blame the messenger.
> 
>   If you have a problem with the statement that 4282 is wrong, go fight
> with the i18n people.  Once you've done that, go force all of the AAA
> vendors to implement the other recommendations of 4282.
> 
>   Or, you can attack me for pointing out the problems.  Which is
> easier?

"it's wrong" hardly qualifies as "pointing out the problems".  OTOH, this
message (was it so hard?) may.

> 
> 
>   This subject was discussed last year on the on RADEXT list.  See
> message subjects with 4282 in them.  I don't see you having any
> comments
> at that time.  I also see a number of comments from other people who
> also claim to see problems with 4282.
> 
> 
>   At a minimum:
> 
> - the mapping requirements are likely wrong.  Intermediate nodes
>   should not be doing comparisons on the username portion of an NAI.
> 
> - the bidirectional rules are superseded by later BIDI documents
> 
> - the suggestion to reject NAIs with unassigned code points
>   means that those code points can never be assigned, as conformant
>   implementations that have not yet been updated will reject those
> NAIs.
> 
> - the suggestion to encode NAIs as punycode is implemented by no one.
> 
> - the suggest for intermediate nodes to normalize the NAI is
>   unnecessary, can cause inter-operability requirements, and is
>   implemented by no one.
> 
> 
>   Again, these are not *my* points.  I'm just repeating comments from
> *other* people on the RADEXT mailing list.
> 
>   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: Wed, 09 Sep 2009 09:31:37 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 11:29:59 +0200

Dan Romascanu [mailto://[email-masked]] writes:

> > Much of RFC 4282 is simply wrong.
> 
> If this is the case, I do not believe that an Errata is the right
> instrument to fix the situation, but rather the WG working on a
> document
> to obsolete and replace RFC 4282 or simply declare it Historical.
> 
> I would invite other opinions from the WG and especially from the
> editors.

Not that I want to question (God forbid!) the godlike opinion of Alan DeKok,
but could we have just a smidgeon of justification for that statement before
tossing RFC 4282?

...

--
to unsubscribe send 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, 09 Sep 2009 08:41:20 +0000
Content-class: urn:content-classes:message
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 10:40:24 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "RFC Errata System" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

> Much of RFC 4282 is simply wrong. 

If this is the case, I do not believe that an Errata is the right
instrument to fix the situation, but rather the WG working on a document
to obsolete and replace RFC 4282 or simply declare it Historical. 

I would invite other opinions from the WG and especially from the
editors. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 6:35 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Romascanu, 
> Dan (Dan); [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [Technical Errata Reported] RFC4282 (1848)
> 
> 
> The following errata report has been submitted for RFC4282, 
> "The Network Access Identifier".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1848
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <[email-masked]>
> 
> Section: 2.4
> 
> Original Text
> -------------
>    o  Normalization requirements, as specified in Section 2.2 of
>       [RFC4013], are also designed to assist in comparisons.
> 
> Corrected Text
> --------------
>   o Normalization is, in general, a bad idea.
> 
> Notes
> -----
> Much of RFC 4282 is simply wrong.
> 
> Normalization can be done only when both the local and 
> character set information is included with the text.  And 
> that information is not included with the username or realm.
> 
> In addition, not all systems will treat "User" the same as 
> "user".  The decision about how to compare user names is site 
> specific.  User name comparisons SHOULD NOT be performed on 
> any system other than the final one that performs user authentication.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, 
> please use "Reply All" to discuss whether it should be 
> verified or rejected. When a decision is reached, the 
> verifying party (IESG) can log in to change the status and 
> edit the report, if necessary. 
> 
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 

--
to unsubscribe send 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, 09 Sep 2009 07:55:55 +0000
Date: Wed, 09 Sep 2009 09:54:45 +0200
From: Alan DeKok <[email-masked]>
To: Stig Venaas <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"

Stig Venaas wrote:
> I'm a bit confused by that first sentence. The TCP session might be
> reset without the watchdog marking it down. Wouldn't that be sufficient
> to say that the connection is down?

  Yes.

> 2. Should the term RadSec be replaced with RADIUS over TLS?

  Yes.  The decision to remove the RadSec name was made after the draft
had been submitted.

  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, 08 Sep 2009 20:38:37 +0000
Date: Tue, 08 Sep 2009 13:38:10 -0700
From: Stig Venaas <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item

Bernard Aboba wrote:
> This is a reminder of the ongoing call for review of the document "DTLS 
> as a Transport Layer for RADIUS" for adoption as a RADEXT WG work item.  
> This document is being targeted at Experimental status.
>  
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-dtls
> 
> The original call for review expired August 7, 2009, but no comments 
> were received.  This call for input will last until October 2, 2009.  

I'm in favour of adoption,

Stig

> Please send email to the RADEXT WG mailing list indicating whether you 
> support adoption of this document as a RADEXT WG work item.  If you have 
> comments on the document, please also send these to the list in the 
> format described on the RADEXT WG Issues list:
> http://www.drizzle.com/~aboba/RADEXT/ 
> <http://www.drizzle.com/%7Eaboba/RADEXT/>
> 
> <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> 

--
to unsubscribe send 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, 08 Sep 2009 20:37:20 +0000
Date: Tue, 08 Sep 2009 13:36:50 -0700
From: Stig Venaas <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"

Bernard Aboba wrote:
> This is a reminder of an ongoing RADEXT WG last call on "RADIUS over 
> TCP", prior to sending this document on to the IESG for publication as 
> an Experimental RFC.  The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

Looks like my previous email didn't make it. I think the document is
ready, but two minor comments.

1. The draft says:

    RADIUS clients using RADIUS over TCP MUST NOT decide that a
    connection is down until the application layer watchdog algorithm has
    marked it DOWN ([RFC3539] Appendix A).  RADIUS clients using RADIUS
    over TCP MUST NOT decide that a RADIUS server is unresponsive until
    all TCP connections to it have been marked DOWN.

I'm a bit confused by that first sentence. The TCP session might be
reset without the watchdog marking it down. Wouldn't that be sufficient
to say that the connection is down?

2. Should the term RadSec be replaced with RADIUS over TLS?

Stig

--
to unsubscribe send 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, 08 Sep 2009 20:37:03 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:36:16 -0700

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   If the RADIUS server has to parse it, then complex attributes are
> allowed for authentication and security...

I think the question is why the exemption should be so broad.  The security and authentication attributes described in Appendix B required computation.  That is the RADIUS server had to add code in order to compare the authentication result presented by the RADIUS client with the result it calculated based on its own data. 

However, if the RADIUS server doesn't have to do any computation (e.g. if it is just sending security or authentication-related data to the RADIUS client), then there is no intrinsic reason why RADIUS server code needs to change.  In that case, why should the exemption apply?  

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt;   If the RADIUS server has to parse it, then complex attributes are<br>&gt; allowed for authentication and security...<br><br>I think the question is why the exemption should be so broad.&nbsp; The security and authentication attributes described in Appendix B required computation.&nbsp; That is the RADIUS server had to add code in order to compare the authentication result presented by the RADIUS client with the result it calculated based on its own data. <br><br>However, if the RADIUS server doesn't have to do any computation (e.g. if it is just sending security or authentication-related data to the RADIUS client), then there is no intrinsic reason why RADIUS server code needs to change.&nbsp; In that case, why should the exemption apply?&nbsp; <br></body>
</html>
--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_--

--
to unsubscribe send 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, 08 Sep 2009 20:13:01 +0000
Date: Tue, 08 Sep 2009 22:12:04 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Issue 313:  Security Exemption

David B. Nelson wrote:
> I don't think that the "for purposes other than authentication or security?"
> text really addresses the inherent ambiguity.  My understanding is that the
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS"
> limitation, and thus remains an open loop-hole, IMO.

  ?

   Does the attribute:

    * define a complex data type
    * that the RADIUS server and/or client will not treat as opaque data
      (see Section A.1.3)

  If the RADIUS server can treat it as opaque data, then it falls under
the purview of A.1.3.  It is permitted, independent of it being used for
authentication, security, or anything else.

  If the RADIUS server has to parse it, then complex attributes are
allowed for authentication and security...

  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, 08 Sep 2009 18:18:35 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 11:17:56 -0700

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I agree.  My reading of the current, as well as that of others, however, is
> that *any* security related attribute, whether in support of the RADIUS
> protocol or some external entity, qualifies for an exemption to be designed
> as a complex type.  In that regard, "security" attributes for any usage are
> covered by this exemption.

OK.  I would agree that this is too broad.  

I think the idea was to exempt attributes where *computation* was required on the server and client (e.g. Digest Authentication, CHAP, etc.).   But if there is no computation occurring, or if the attribute could be construed as opaque, I don't think the exemption is appropriate. 

For example, consider a complex "Security Policy Attribute" sent from server to client.  From the server point of view, there is no computation involved, the server just sends the attribute to the client, who is expected to understand it.  In such a situation, there is no intrinsic reason why server code changes should be required.  Does such an attribute deserve an exemption?  I would say no. 

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>&gt; I agree.  My reading of the current, as well as that of others, however, is<br>&gt; that *any* security related attribute, whether in support of the RADIUS<br>&gt; protocol or some external entity, qualifies for an exemption to be designed<br>&gt; as a complex type.  In that regard, "security" attributes for any usage are<br>&gt; covered by this exemption.<br><br>OK.&nbsp; I would agree that this is too broad.&nbsp; <br><br>I think the idea was to exempt attributes where *computation* was required on the server and client (e.g. Digest Authentication, CHAP, etc.).&nbsp;&nbsp; But if there is no computation occurring, or if the attribute could be construed as opaque, I don't think the exemption is appropriate. <br><br>For example, consider a complex "Security Policy Attribute" sent from server to client.&nbsp; From the server point of view, there is no computation involved, the server just sends the attribute to the client, who is expected to understand it.&nbsp; In such a situation, there is no intrinsic reason why server code changes should be required.&nbsp; Does such an attribute deserve an exemption?&nbsp; I would say no. <br></body>
</html>
--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_--

--
to unsubscribe send 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, 08 Sep 2009 17:56:55 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:56:58 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba wrote...

> IMHO, if an attribute doesn't relate to RADIUS, but to
> some external entity, then it is effectively opaque and
> shouldn't be a complex attribute.

I agree.  My reading of the current, as well as that of others, however, is
that *any* security related attribute, whether in support of the RADIUS
protocol or some external entity, qualifies for an exemption to be designed
as a complex type.  In that regard, "security" attributes for any usage are
covered by this exemption.

> I think that's what Alan's suggested text says, more or less.

It seems to me be way toward the "less".  I think the applicability needs to
be clarified.

--
to unsubscribe send 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, 08 Sep 2009 17:48:59 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 10:48:30 -0700

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I don't think that the "for purposes other than authentication or security?"
> text really addresses the inherent ambiguity.  My understanding is that the
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS"
> limitation, and thus remains an open loop-hole, IMO.

Appendix B talks about complex attributes.  I'm not sure which of these would be considered "internal to RADIUS" and which would not be.  

For example, is Digest Authentication (RFC 5090) internal to RADIUS?  What about CHAP?  Or are we talking about Message-Authenticator?  

IMHO, if an attribute doesn't relate to RADIUS, but to some external entity, then it is effectively opaque and shouldn't be a complex attribute.  I think that's what Alan's suggested text says, more or less. 

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>&gt; I don't think that the "for purposes other than authentication or security?"<br>&gt; text really addresses the inherent ambiguity.  My understanding is that the<br>&gt; exemption is for authentication or security mechanisms internal to the<br>&gt; RADIUS protocol.  The revised text does not make that "internal to RADIUS"<br>&gt; limitation, and thus remains an open loop-hole, IMO.<br><br>Appendix B talks about complex attributes.&nbsp; I'm not sure which of these would be considered "internal to RADIUS" and which would not be.&nbsp; <br><br>For example, is Digest Authentication (RFC 5090) internal to RADIUS?&nbsp; What about CHAP?&nbsp; Or are we talking about Message-Authenticator?&nbsp; <br><br>IMHO, if an attribute doesn't relate to RADIUS, but to some external entity, then it is effectively opaque and shouldn't be a complex attribute.&nbsp; I think that's what Alan's suggested text says, more or less. <br></body>
</html>
--_313bde98-40bc-4051-b87d-180d21cb3a5f_--

--
to unsubscribe send 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, 08 Sep 2009 17:06:01 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:05:35 -0400
Organization: Elbrys Networks, Inc.

Sorry for the late response.  I'm still recuperating, and have not remained
on top of my IETF correspondence.

Alan DeKok wrote...

> >   RADIUS could transport parameters for *another* protocol.  Those
> > attributes are not security related.  They either follow the RADIUS data
> > model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> > simply transporting on the behalf of the other protocol.
> 
>   Suggested text in Section A.2.2.:
> 
> A.2.2. Complex Data Types
> 
>    Does the attribute:
> 
>    * define a complex data type
>    * that the RADIUS server and/or client will not treat as opaque data
>      (see Section A.1.3)
>    * for purposes other than authentication or security?
> 
>    If the answers to all of the above items are "yes", this data type
>    SHOULD be replaced
>    with simpler types, as discussed above in Section A.2.1.  Also see
>    Section 2.1.3 for a discussion of why complex types are problematic.

I don't think that the "for purposes other than authentication or security?"
text really addresses the inherent ambiguity.  My understanding is that the
exemption is for authentication or security mechanisms internal to the
RADIUS protocol.  The revised text does not make that "internal to RADIUS"
limitation, and thus remains an open loop-hole, IMO.

--
to unsubscribe send 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, 08 Sep 2009 15:42:35 +0000
Date: Tue, 8 Sep 2009 08:38:52 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC4282 (1850)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfcB82&eid50

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.4

Original Text
-------------
   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

Corrected Text
--------------
  o Unassigned code points MUST be ignored

Notes
-----
Unassigned code points sometimes go through a process called "assignment".  This means that they suddenly become valid.

Implementations that forbid unassigned code points will not be updated when the standards change to assign them.  Therefore, they should ignore unassigned code points.

Happily, this is what all implementations do.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send 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, 08 Sep 2009 15:38:45 +0000
Date: Tue, 8 Sep 2009 08:37:04 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC4282 (1849)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfcB82&eid49

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.4

Original Text
-------------
   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

Corrected Text
--------------
  o Bidrectional characters are handled in a site-specific fashion

Notes
-----
The rules in [4013] have shortcomings.  Updates are in:

http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send 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, 08 Sep 2009 15:37:22 +0000
Date: Tue, 8 Sep 2009 08:35:21 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC4282 (1848)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfcB82&eid48

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.4

Original Text
-------------
   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

Corrected Text
--------------
  o Normalization is, in general, a bad idea.

Notes
-----
Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set information is included with the text.  And that information is not included with the username or realm.

In addition, not all systems will treat "User" the same as "user".  The decision about how to
compare user names is site specific.  User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send 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, 08 Sep 2009 15:17:44 +0000
Date: Tue, 08 Sep 2009 17:17:19 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RADIUS Errata #816 (RFC 4282)

  Could we not file an errata against 4282 saying  "This document is
nearly completely wrong: no one does what it recommends".

  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, 08 Sep 2009 15:15:02 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT WG mailing list issues
Date: Tue, 8 Sep 2009 08:14:34 -0700

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A number of you have sent me email noting that one or more of the following problems:

a. Your posts are not making it to the list, when sent from a subscribed email address;
b. Your posts are not making it to the list, when sent from an unsubscribed email address;
c. You are not receiving posts sent to the list;

Based on my own experience and examination of the logs, the RADEXT WG list appears to have stopped functioning this weekend and messages sent to the list during that time were not sent out.  The list is now functioning again, but the archive has remained down since September 2, 2009.

Be aware that the RADEXT WG list only allows subscribers to post; non-subscriber emails are bounced.  

If you have sent mail to the list that was not sent out, please resend it. 

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

A number of you have sent me email noting that one or more of the following problems:<br><br>a. Your posts are not making it to the list, when sent from a subscribed email address;<br>b. Your posts are not making it to the list, when sent from an unsubscribed email address;<br>c. You are not receiving posts sent to the list;<br><br>Based on my own experience and examination of the logs, the RADEXT WG list appears to have stopped functioning this weekend and messages sent to the list during that time were not sent out.&nbsp; The list is now functioning again, but the archive has remained down since September 2, 2009.<br><br>Be aware that the RADEXT WG list only allows subscribers to post; non-subscriber emails are bounced.&nbsp; <br><br>If you have sent mail to the list that was not sent out, please resend it. <br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><br></td></tr></tbody></table></body>
</html>
--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_--

--
to unsubscribe send 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, 08 Sep 2009 15:13:09 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #753 (RFC 4282)
Date: Tue, 8 Sep 2009 08:11:19 -0700

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Anyone have an opinion on this one? As I recall, the use of 'FF' was intentional. 

Status: Reported

Type: Technical

Reported By: Frank Ellermann

Date Reported: 2006-08-14

Section 2.1 says:

   c           =/ %x80-FF ; UTF-8-Octet      allowed (not in RFC 2486)
                          ; Where UTF-8-octet is any octet in the
                          ; multi-octet UTF-8 representation of a
                          ; unicode codepoint above %x7F.
                          ; Note that c must also satisfy rules in
                          ; Section 2.4, including, for instance,
                          ; checking that no prohibited output is
                          ; used (see also Section 2.3 of
                          ; [RFC4013]).
   x           =  %x00-FF ; all 128 ASCII characters, no exception;
                          ; as well as all UTF-8-octets as defined
                          ; above (this was not allowed in
                          ; RFC 2486).  Note that x must nevertheless
                          ; again satisfy the Section 2.4 rules.

It should say:

[see below]

Notes:

Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?

 EMAILING FOR THE GREATER GOOD
Join me
--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

Anyone have an opinion on this one? As I recall, the use of 'FF' was intentional. <br><br>
<b>Status: Reported<br>
Type: Technical<br>
</b><br>
Reported By: Frank Ellermann<br>
Date Reported: 2006-08-14<br>
<br>
Section 2.1 says:
<br>
<pre class="EC_rfctext">   c           =/ %x80-FF ; UTF-8-Octet      allowed (not in RFC 2486)<br>                          ; Where UTF-8-octet is any octet in the<br>                          ; multi-octet UTF-8 representation of a<br>                          ; unicode codepoint above %x7F.<br>                          ; Note that c must also satisfy rules in<br>                          ; Section 2.4, including, for instance,<br>                          ; checking that no prohibited output is<br>                          ; used (see also Section 2.3 of<br>                          ; [RFC4013]).<br>   x           =  %x00-FF ; all 128 ASCII characters, no exception;<br>                          ; as well as all UTF-8-octets as defined<br>                          ; above (this was not allowed in<br>                          ; RFC 2486).  Note that x must nevertheless<br>                          ; again satisfy the Section 2.4 rules.<br></pre>
It should say:<br>
<pre class="EC_rfctext">[see below]<br></pre>
Notes:<br>
<p class="EC_simpleindent">
Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?
</p>
<hr><br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_--

--
to unsubscribe send 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, 08 Sep 2009 15:12:35 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #757 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:55 -0700

--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My recommendation is that this errata be accepted. 
Status: Reported

Type: Technical

Reported By: Peter Koch

Date Reported: 2005-12-13

Section 2.6 says:

   The BNF of the realm portion allows the realm to begin with a digit,
   which is not permitted by the BNF described in [RFC1035].  This
   change was made to reflect current practice; although not permitted
   by the BNF described in [RFC1035], Fully Qualified Domain Names
   (FQDNs) such as 3com.com are commonly used and accepted by current
   software.

It should say:

[not supplied]

Notes:

section 2.6 missed the update of the hostname syntax in

RFC 1123, section 2.1.

RFC 1123 (STD 3) 2.1 allows labels starting with a <digit>

in fully qualified domain names of a host, RFC 1035 (STD 13)

2.3.1 still wants labels starting with a <letter>.

 EMAILING FOR THE GREATER GOOD
Join me
--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

<b>My recommendation is that this errata be accepted. <br></b><b>Status: Reported<br>
Type: Technical<br>
</b><br>
Reported By: Peter Koch<br>
Date Reported: 2005-12-13<br>
<br>
Section 2.6 says:
<br>
<pre class="EC_rfctext">   The BNF of the realm portion allows the realm to begin with a digit,<br>   which is not permitted by the BNF described in [RFC1035].  This<br>   change was made to reflect current practice; although not permitted<br>   by the BNF described in [RFC1035], Fully Qualified Domain Names<br>   (FQDNs) such as 3com.com are commonly used and accepted by current<br>   software.<br></pre>
It should say:<br>
<pre class="EC_rfctext">[not supplied]<br></pre>
Notes:<br>
<p class="EC_simpleindent">
section 2.6 missed the update of the hostname syntax in<br>
RFC 1123, section 2.1.<br>
<br>
RFC 1123 (STD 3) 2.1 allows labels starting with a &lt;digit&gt;<br>
in fully qualified domain names of a host, RFC 1035 (STD 13)<br>
2.3.1 still wants labels starting with a &lt;letter&gt;.
</p><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_154e7599-aefa-4c44-b34b-e27990b1da86_--

--
to unsubscribe send 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, 08 Sep 2009 15:12:05 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #816 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:28 -0700

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My recommendation is that this errata be accepted "Pending Update". 

Status: Reported

Type: Technical

Reported By: Alfred Hoenes

Date Reported: 2005-12-18

Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.

In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !

Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in 
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!

It should say:

[see above]

Notes:

from pending

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

<b>My recommendation is that this errata be accepted "Pending Update". <br></b><br><b><br></b><br><b>Status: Reported<br>
Type: Technical<br>
</b><br>
Reported By: Alfred Hoenes<br>
Date Reported: 2005-12-18<br>
<br>
&nbsp;<br>
<pre class="EC_rfctext">Unfortunately, the text of that RFC does not fully reflect the<br>established state of the IETF standards, by referring to obsolete<br>documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,<br>e.g., STD 3, RFC 1123, and RFC 2821.<br><br>In particular, the text of RFC 4282 repeatedly (e.g. in Section<br>2.6.) emphasizes making a deviation from established standards<br>for host / domain names.<br><br>This is not true!<br>The pretended deviation in fact reflects the current standards.<br><br>The modification to RFC 952, RFC 821, et al. has already been<br>introduced into the IETF Standards by STD 3, RFC 1123 (Host<br>Requirements, Part II), published 16 years ago, in October 1989.<br>Section 2.1 of that RFC, on page 13, says:<br><br>    "One aspect of host name syntax is hereby changed: the<br>     restriction on the first character is relaxed to allow<br>     either a letter or a digit. Host software MUST support<br>     this more liberal syntax."<br><br>and continues saying:<br><br>    "Host software MUST handle host names of up to 63 characters<br>     and SHOULD handle host names of up to 255 characters."<br><br>Therefore, it would have been strongly advisable to point out<br>on page 6 of RFC 4282, in Section 2.2, first bullet, that the<br>named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!<br><br>Note: IMHO, it is a fundamental design flaw of RADIUS and certain<br>other protocols using TLVs, AVPs, -- or however similar protocol<br>objects are named -- to specify that the 'length' information<br>(being stored in a single octet) is to comprise the cumulative<br>size of the Type, Length and Value fields, instead of just giving<br>the size of the Value (payload) field; the latter solution would<br>always allow to fully exhaust the total range of an 8-bit unsigned<br>Length and thereby allow payload octet strings of size 0..255 !<br><br><br>Similarly, RFC 4282 ignores the standardization state of the<br>proprietary historic tunnelling protocols that have served as<br>'precursors with major deficiencies to learn from' for the<br>development of L2TP, the only comparable protocol named in <br>RFC 4282 that is on the IETF Standards Track.<br><br>  o   L2F [RFC2341] has been published for information only<br>      as a Historic RFC 'ab initio'.<br><br>  o   PPTP [RFC2637] has purposely been rejected by the IETF --<br>      because of its well known significant security flaws, among<br>      other issues, and the Informational RFC 2637 has been<br>      published with a very clear IESG Note to this end.<br><br>I am surprised that a new Standards Track RFC is getting published<br>that repeatedly refers to obsolete protocols equally as to official<br>protocols, in a manner that does not make clear the distinction.<br>The continued unreflected use of PPTP, in particular, is seen by<br>major security consultants as 'one of the most widespread trojan<br>horses' in the current Internet.  We should do everything to<br>communicate and emphasize the 1998/1999 decisions of the IETF and<br>IESG and the reasons behind it, and push the evolved standards!<br><br><br></pre>
It should say:<br>
<pre class="EC_rfctext">[see above]<br></pre>
Notes:<br>
<p class="EC_simpleindent">
from pending
</p><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_--

--
to unsubscribe send 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, 08 Sep 2009 15:11:35 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #1326 (RFC 5090)
Date: Tue, 8 Sep 2009 08:10:02 -0700

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Errata ID: 1326

My recommendation is that this errata be accepted "Pending Update". 

Status: Reported

Type: Technical

Reported By: Alfred Hoenes

Date Reported: 2008-02-17

Throughout the document, when it says:

a)       header

b)       headers

c)       Header

It should say:

a)       header field

b)       header fields

c)       Header Field

Notes:

As a Standards Track document, RFC 5090 should use established

IETF standard terminology, and not fall back to common sluggish

and confusing terminology.  Concise Ref.:  RFC 4249, Section 3.1.1.

There are 24 instances of case a) throughout the RFC;

only Section 3.20 makes proper use of the IETF standard

terminology; case b) occurs twice in the RFC;

case c) applies to the title of Section 2.1.3.

 EMAILING FOR THE GREATER GOOD
Join me
--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;</style>Errata ID: 1326<br><br>
<b>My recommendation is that this errata be accepted "Pending Update". <br></b><br><b><br></b><br><b>Status: Reported<br>
Type: Technical<br>
</b><br>
Reported By: Alfred Hoenes<br>
Date Reported: 2008-02-17<br>
<br>
Throughout the document, when it says:
<br>
<pre class="EC_rfctext">a)       header<br><br>b)       headers<br><br>c)       Header<br></pre>
It should say:<br>
<pre class="EC_rfctext">a)       header field<br><br>b)       header fields<br><br>c)       Header Field<br></pre>
Notes:<br>
<p class="EC_simpleindent">
As a Standards Track document, RFC 5090 should use established<br>
IETF standard terminology, and not fall back to common sluggish<br>
and confusing terminology.  Concise Ref.:  RFC 4249, Section 3.1.1.<br>
<br>
There are 24 instances of case a) throughout the RFC;<br>
only Section 3.20 makes proper use of the IETF standard<br>
terminology; case b) occurs twice in the RFC;<br>
case c) applies to the title of Section 2.1.3.
</p>
<hr><br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_--

--
to unsubscribe send 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, 08 Sep 2009 15:10:32 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #867 (RFC 4668)
Date: Tue, 8 Sep 2009 08:09:23 -0700

--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[BA] IMHO, Alfred is correct that RFC 4668 covers both IPv4 and IPv6. 
Since the abstract makes this clear, I don't think that the title needs to be changed. 

With respect to the term "MIB module", I would agree with Alfred that the term
"MIB" would have been more appropriate.

Overall I'd recommend that this errata be accepted "Pending Revision". 

Status: Reported

Type: Editorial

Reported By: Alfred Hoenes

Date Reported: 2006-11-06

misleading RFC title, including abuse of defined terms
(for RFCs 4668 - 4671)

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of all four RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".

--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>

<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

<b>[BA] IMHO, Alfred is correct that RFC 4668 covers both IPv4 and IPv6. <br>Since the abstract makes this clear, I don't think that the title needs to be changed. <br><br>With respect to the term "MIB module", I would agree with Alfred that the term<br>"MIB" would have been more appropriate.<br><br>Overall I'd recommend that this errata be accepted "Pending Revision". <br><br><br>Status: Reported<br>
Type: Editorial<br>
</b><br>
Reported By: Alfred Hoenes<br>
Date Reported: 2006-11-06<br>

<br>
<pre class="EC_rfctext">misleading RFC title, including abuse of defined terms<br>(for RFCs 4668 - 4671)<br><br>IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.<br>In fact, the new RFCs extend the RADIUS MIB modules to cover<br>IPv6, but they are not IPv6 specific!<br>Perhaps, better wording would have been "... for IPv4 and IPv6".<br><br>Furthermore, a very 'popular' clash of terms shines up here.<br>As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and<br>re-stated in the boilerplate Section 3, "The Internet-Standard<br>Management Framework", of all four RFCs, there's just one single<br>Management Information Base (MIB) comprised of various "MIB modules".<br>Thus, throughout the titles and the text bodies of the RFCs, the<br>proper term, "RADIUS ... MIB module" should be used instead of the<br>rather sluggish "RADIUS ... MIB".<br></pre><br><br></body>
</html>
--_3901da34-350f-4435-b4be-0507c9478d20_--

--
to unsubscribe send 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, 08 Sep 2009 15:00:33 +0000
Date: Tue, 08 Sep 2009 16:59:31 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RADIUS Errata #1407 (RFC 5176)

Bernard Aboba wrote:
> *My recommendation is that this errata be accepted.  As Avi points out,
> the CUI attribute is opaque and therefore not parseable by the Dynamic
> Authorization Server.

  I agree.

  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, 08 Sep 2009 08:25:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Test
Date: Tue, 8 Sep 2009 10:24:05 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I have them in my inbox! ;)

Lionel 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Alan DeKok
> Envoyé : lundi 7 septembre 2009 22:27
> À : 'radext mailing list'
> Objet : Test
> 
> 
>   Is the mailing list fixed?  My earlier posts aren't in the 
> archives...
> 
>   Did anyone other than Bernard see my comments on the issues 
> in the guidelines document?
> 
>   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/>
> 

--
to unsubscribe send 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, 07 Sep 2009 21:59:22 +0000
Date: Mon, 7 Sep 2009 17:09:36 -0400
Subject: Re: Test
From: Greg Weber <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: radext mailing list <[email-masked]>

On Mon, Sep 7, 2009 at 4:26 PM, Alan DeKok<[email-masked]> wrote:
>  Is the mailing list fixed?  My earlier posts aren't in the archives...
>
>  Did anyone other than Bernard see my comments on the issues in the
> guidelines document?

Yes.  They appear to have gone to the list, but not the archive.

Greg

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

--
to unsubscribe send 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, 07 Sep 2009 20:58:47 +0000
Date: Mon, 07 Sep 2009 22:26:36 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Test

  Is the mailing list fixed?  My earlier posts aren't in the archives...

  Did anyone other than Bernard see my comments on the issues in the
guidelines document?

  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: Mon, 07 Sep 2009 19:17:13 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADIUS Errata #1407 (RFC 5176)
Date: Mon, 7 Sep 2009 11:34:55 -0700

--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My recommendation is that this errata be accepted.  As Avi points out, 
the CUI attribute is opaque and therefore not parseable by the Dynamic
Authorization Server. 

Status: Reported

Type: Technical

Reported By: Avi Lior

Date Reported: 2008-04-09

Section 6.1 says:

Typically, the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name or Chargeable-User-Identity Attribute, and determine the
   corresponding RADIUS servers in the realm routing tables.

It should say:

Typically, the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name and determine the
   corresponding RADIUS servers in the realm routing tables.

Notes:

Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:

"RADIUS entities other than the Home RADIUS

      server MUST treat the CUI content as an opaque token, and SHOULD

      NOT perform operations on its content other than a binary equality

      comparison test, between two instances of CUI."

 EMAILING FOR THE GREATER GOOD
Join me
--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<b>My recommendation is that this errata be accepted.&nbsp; As Avi points out, <br>the CUI attribute is opaque and therefore not parseable by the Dynamic<br>Authorization Server. <br><br><br>Status: Reported<br>
Type: Technical<br>
</b><br>
Reported By: Avi Lior<br>
Date Reported: 2008-04-09<br>

Section 6.1 says:
<BR>
<pre class="rfctext">Typically, the Dynamic Authorization Server will extract the realm<br>   from the Network Access Identifier [RFC4282] included within the<br>   User-Name or Chargeable-User-Identity Attribute, and determine the<br>   corresponding RADIUS servers in the realm routing tables.<br></pre>
It should say:<BR>
<pre class="rfctext">Typically, the Dynamic Authorization Server will extract the realm<br>   from the Network Access Identifier [RFC4282] included within the<br>   User-Name and determine the<br>   corresponding RADIUS servers in the realm routing tables.<br></pre>
Notes:<BR>
<p class="simpleindent">
Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:<br>
"RADIUS entities other than the Home RADIUS<br>
      server MUST treat the CUI content as an opaque token, and SHOULD<br>
      NOT perform operations on its content other than a binary equality<br>
      comparison test, between two instances of CUI."
</p><br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_51481470-7a9c-4acb-9722-06e329bc25e8_--

--
to unsubscribe send 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, 06 Sep 2009 22:13:38 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send 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, 06 Sep 2009 22:04:43 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send 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, 06 Sep 2009 20:55:09 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send 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, 06 Sep 2009 20:46:07 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send 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, 04 Sep 2009 22:50:03 +0000
Date: Fri, 04 Sep 2009 22:50:03 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document

Bernard Aboba wrote:
>> The design guidelines document can talk about things that exist today.
>> if other documents add new RADIUS functionality, they can mention that
>> they update the design guidelines document.
> 
> Seems reasonable to me.  Could you post a proposal on text to be deleted?

  All text that references [EXTEN], or extended attributes. A quick pass
through the document yeilds:

   Specifications that do not follow the
   guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED.
->
   Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.
   Changes to the RADIUS data model are NOT
   RECOMMENDED, but if performed, SHOULD follow the IETF process.

  i.e. we can't retro-actively forbid the various SDOs from adding all
kinds of stuff to the data model.

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.  New attributes SHOULD use the grouping
   method described in [EXTEN].
->
   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

2.2.  Extended RADIUS Attributes
->
	<delete the entire section>

  In Section 2.3:

   If additional functionality is required, the format defined in
   [EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
->
	<delete the above text.

  In Section 3:

   Recent extensions to the RADIUS data model such as [EXTEN] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.
->
	<delete the above text>

  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, 04 Sep 2009 17:53:41 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 311: IESG DISCUSS comments
Date: Fri, 4 Sep 2009 09:48:03 -0700

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

looks good.

> Date: Fri, 4 Sep 2009 10:13:07 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: Issue 311: IESG DISCUSS comments
> 
> Bernard Aboba wrote:
> > You might also mention that firewalls and other filtering devices often
> > discard fragments.
> 
>   OK.
> 
> > Jari is correct that allocation requests will be handled according to
> > RFC 3575,
> > but as part of the Expert Review process, Design Guidelines will
> > presumably be
> > consulted.  So while self-allocation is certainly not a good practice,
> > the whole
> > point of IANA allocation is to enable consistent allocation.  Perhaps
> > the text
> > can be clear that the recommendations are relevant to Expert Reviewers
> > appointed under the IANA considerations of RFC 3575, not for IANA itself.
> 
>   OK.  I suggest adding a first bullet about this point to the IANA
> considerations section:
> 
> ...
> This document does not require that the IANA update any existing
> registry or create any new registry, but includes information that
> affects the IANA, which:
> 
> * includes specific guidelines for Expert Reviewers appointed
>   under the IANA considerations of [RFC3575]
> * includes guidelines that recommend against self allocation from
>   ...
> 
>   Alan DeKok.

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
looks good.<br><br><br>&gt; Date: Fri, 4 Sep 2009 10:13:07 +0200<br>&gt; From: [email-masked]<br>&gt; To: [email-masked]<br>&gt; CC: [email-masked]<br>&gt; Subject: Re: Issue 311: IESG DISCUSS comments<br>&gt; <br>&gt; Bernard Aboba wrote:<br>&gt; &gt; You might also mention that firewalls and other filtering devices often<br>&gt; &gt; discard fragments.<br>&gt; <br>&gt;   OK.<br>&gt; <br>&gt; &gt; Jari is correct that allocation requests will be handled according to<br>&gt; &gt; RFC 3575,<br>&gt; &gt; but as part of the Expert Review process, Design Guidelines will<br>&gt; &gt; presumably be<br>&gt; &gt; consulted.  So while self-allocation is certainly not a good practice,<br>&gt; &gt; the whole<br>&gt; &gt; point of IANA allocation is to enable consistent allocation.  Perhaps<br>&gt; &gt; the text<br>&gt; &gt; can be clear that the recommendations are relevant to Expert Reviewers<br>&gt; &gt; appointed under the IANA considerations of RFC 3575, not for IANA itself.<br>&gt; <br>&gt;   OK.  I suggest adding a first bullet about this point to the IANA<br>&gt; considerations section:<br>&gt; <br>&gt; ...<br>&gt; This document does not require that the IANA update any existing<br>&gt; registry or create any new registry, but includes information that<br>&gt; affects the IANA, which:<br>&gt; <br>&gt; * includes specific guidelines for Expert Reviewers appointed<br>&gt;   under the IANA considerations of [RFC3575]<br>&gt; * includes guidelines that recommend against self allocation from<br>&gt;   ...<br>&gt; <br>&gt;   Alan DeKok.<br></body>
</html>
--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_--

--
to unsubscribe send 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, 04 Sep 2009 08:21:48 +0000
Date: Fri, 04 Sep 2009 10:21:02 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document

Bernard Aboba wrote:
> The reason why we ended up with a normative reference was because there
> were normative statements preceeding the reference.  So I don't think it's
> enough just to change the reference to informative; you'll also need to
> change
> the text.

  I think it's simplest to simply remove all references to the extended
attributes document.  We can then mark it as updating the design
guidelines document, to permit the extended attribute format.

  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, 04 Sep 2009 08:14:24 +0000
Date: Fri, 04 Sep 2009 10:13:07 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 311: IESG DISCUSS comments

Bernard Aboba wrote:
> You might also mention that firewalls and other filtering devices often
> discard fragments.

  OK.

> Jari is correct that allocation requests will be handled according to
> RFC 3575,
> but as part of the Expert Review process, Design Guidelines will
> presumably be
> consulted.  So while self-allocation is certainly not a good practice,
> the whole
> point of IANA allocation is to enable consistent allocation.  Perhaps
> the text
> can be clear that the recommendations are relevant to Expert Reviewers
> appointed under the IANA considerations of RFC 3575, not for IANA itself.

  OK.  I suggest adding a first bullet about this point to the IANA
considerations section:

...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, which:

* includes specific guidelines for Expert Reviewers appointed
  under the IANA considerations of [RFC3575]
* includes guidelines that recommend against self allocation from
  ...

  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: Thu, 03 Sep 2009 16:33:38 +0000
Date: Thu, 03 Sep 2009 17:27:20 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 311: IESG DISCUSS comments

> The first issue is that Section 2.3 suggests 16-bit vendor space
> attribute number fields to replace the existing 8-bit recommendation.
> 
> There are a couple of problems with this. First, if you really mean
> to change the recommendation, then Updates: RFC 2865 header in the
> beginning of the document would have been appropriate.

  Can a BCP update a standards track document?

> Secondly, while I agree with the advice of going for 16 bits, the
> document is silent on some of the issues involved in such a change,
> such as:
> 
> - Does RADIUS dictionary software support the VSA format for 16 bits, 8
>   bits, or both?

  Most common RADIUS implementations support both.

> - How do you cleanly print or report VSAs when you do not know if the
>   field size is 8 or 16 bits? I realize that this situation already
>   exists since the format was never required to be followed, but
>   your new recommendation makes a potential problem much more likely
>   to appear. Previously, you could print something like Vendor = ACME,
>   Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

  The key is that VSAs depend on a Vendor-Id.  See below.

> - Can a vendor who moved from 8 bits to 16 bits deal with this?

  Suggested text to resolve this issue:

Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the
on-the-wire format of a VSA.  Vendors therefore SHOULD NOT use
multiple formats for VSAs that are associated with a particular Vendor
Id.  A vendor wishing to use multiple VSA formats, SHOULD request one
Vendor Id for each VSA format that they will use.

> Comment [2009-05-07]:
> I do agree that for functionality FOO, both the functionality itself
> and the MIB, RADIUS, etc. work should take place in the same standards
> body. However, Section 3.1 could have said a couple of additional things
> as well:
> 
> The issues of attribute space and choice of forum are distinct; there
> is no reason why IETF couldn't use its own vendor code, for instance.

  Yes.  I don't see a need to mention that in this document.

> The section also does not mention one of the potential drawbacks of
> SDO-driven development model: it is easy to come up with a number of
> different solutions to the same generic problem, as opposed to finding
> a common solution.

  Section 3.1.3 says:

   Any new RADIUS attributes or values intended for interoperable use
   across a broad spectrum of the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from the RADIUS
   standard space.

> Ralph Droms:
> 
> Comment [2009-04-20]:
> Trivial: does the "text" data type include a trailing '\0' byte?  I ask because
> there has been confusion about this point in DHCP options and it might be good
> to make the convention explicit.

 RFC 2865 Section 5 already states explicitly that trailing '\0' bytes
are not to be used.

> Lars Eggert:
> 
> Comment [2009-04-20]:
> 
> Section 2.1.1, paragraph 2:
>>    The Length field in the RADIUS packet header is defined in [RFC2865]
>>    Section 3.  It is noted there that the maximum length of a RADIUS
>>    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
>>    assume that a RADIUS implementation can successfully process RADIUS
>>    packets larger than 4096 octets.
> 
>   You may want to point out that even with messages less than 4096 but
>   larger than the PMTU, persistent IP fragmentation will be incurred,
>   which makes communication much more brittle, and might even want to
>   suggest that therefore RADIUS messages should be kept as small as
>   possible. See RFC5405 Section 3.2.

  Suggested text in 2.1.1:

Even when packets are less than 4096 octets, they may be larger than
the Path Maximum Transmission Unit (PMTU).  Any packet larger than the
PMTU will be fragmented, making communications more brittle.
Transport of fragmented UDP packets appears to be a poorly tested code
path on network devices.  Some devices appear to be incapable of
transporting fragmented UDP packets, making it difficult to deploy
RADIUS in a network where those devices are deployed.  We RECOMMEND
that RADIUS messages be kept as small possible.

> Adrian Farrel:
> 
> Comment [2009-04-18]:
> Trivial, but...
> Section 2.1.1 says that some address data types are in "network
> byte order" while others are "most significant octet first". Is there a reason
> for this difference?

  Tradition.  I suggest changing all references to use "in network byte
order".

> I wonder if the text in seciton 4 should be stronger. You have...
> 
>    This document does not require that the IANA update any existing
>    registry or create any new registry, but includes information that
>    affects the IANA, for example:
> 
>       * includes guidelines that recommend against allocation from the
>         RADIUS standard attribute space in other SDO RADIUS Attribute
>         specifications.
> 
> But, in fact, IANA are bound by the registry rules already laid down and cannot
> make allocations except following IETF process as defined by RFC 3575.

  I think that's what the above text says.  Maybe the text could say:

	... recommend against SELF allocation ...

  The idea is to tell the SDOs that it's a bad idea to avoid IANA.

> Russ Housley:
> 
> Comment [2009-04-20]:
> 
>   The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
>   editorial suggestions.
> 
>   ID nits complains that reference [8] appears in Appendix B.6 but not
>   in the References.

  It's a quote from another document.

>   The Introduction Section should be a non-normative section. However,
>   Section 1.1 uses normative statements (RECOMMENDED and NOT
>   RECOMMENDED) before those terms are defined in Section 1.3.

  The simplest thing to do is to move Section 1.1 to be after the
current Section 1.3.

>   The acronym AAA should be expanded.

  OK, fixed.

>   When referring to the appendixes, I think the draft should talk about
>   appendixes, not about sections. For example, it should talk about
>   Appendix A.5, not about Section A.5.

  OK, fixed.

> Alexey Melnikov:
> 
> Comment [2009-04-21]:
> This is a fine document. Some minor comments:
> 
> 3.3.  RADIUS Operational Model
> 
>    The RADIUS operational model includes several assumptions:
> 
>       * The RADIUS protocol is stateless;
>       * Provisioning of services is not possible within an
>         Access-Reject;
>       * Distinction between authorization checks and user
>         authentication;
>       * Authentication and integrity protection of RADIUS packets;
>       * The RADIUS protocol is a Request/Response protocol.
>       * Packet length restriction.
> 
> Half of this list is comprised from full sentences, the other half is not. I
> would appreciate if you can make this consistent, otherwise it
> is difficult to read/understand.

  I suggest the following re-write:

* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
  Access-Reject;
* There is a distinction between authorization checks and user
  authentication;
* The protocol provices for authentication and integrity
  protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.

> Tim Polk:
> 
> Comment [2009-05-06]:
> It might be valuable to supplement the current security considerations section
> with a discussion of issues that arise if SDOs do not follow the guidelines
> presented here. For example, relying on MTU discovery to support transporting
> large amounts of data could fail and result in denial of service, lost
> accounting data, etc...

  Suggested text:

Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and
denial of service attacks.

> Robert Sparks:
> 
> Comment [2009-04-22]:
> "the above procedure" in 3.1.1 (page 17) could be hard to follow for some
> readers. Recommend providing a more explicit pointer.

  It should say "IETF process" instead of "the above procedure".

  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: Thu, 03 Sep 2009 13:28:02 +0000
Date: Thu, 03 Sep 2009 15:27:54 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document

Bernard Aboba wrote:
> In Section 2.2 and 3 the Design Guidelines document contains normative
> language relating to the Extended Attributes document.  This has
> resulted in a normative dependency on that document.  Given that the
> Extended Attributes document is not yet completed, and can contain its
> own usage guidelines, is the normative reference appropriate?

  No.  The reference should be informative.

  I think it would be OK to simply move the [EXTEN] document from the
"normative" to "informative" section of the references.  Nothing in the
design guideline documents depends on [EXTEN], so there's no reason to
have a normative dependency.

  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: Thu, 03 Sep 2009 13:23:41 +0000
Date: Thu, 03 Sep 2009 15:23:31 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 313:  Security Exemption

>   RADIUS could transport parameters for *another* protocol.  Those
> attributes are not security related.  They either follow the RADIUS data
> model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> simply transporting on the behalf of the other protocol.

  Suggested text in Section A.2.2.:

A.2.2. Complex Data Types

   Does the attribute:

   * define a complex data type
   * that the RADIUS server and/or client will not treat as opaque data
     (see Section A.1.3)
   * for purposes other than authentication or security?

   If the answers to all of the above items are "yes", this data type
   SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.

--
to unsubscribe send 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, 03 Sep 2009 13:16:08 +0000
Date: Thu, 03 Sep 2009 15:15:24 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue 314:  My Problem

> The document assumes a certain implementation and processing model.

  Maybe the document isn't clear.  It assumes a certain *data* model for
RADIUS.  It assumes that maintaining that data model is a good idea.  It
explicitly states that a *typical* RADIUS server uses a data dictionary:

  Section 2.1.3 says:

   ... RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  ...

  Maybe this should be "MANY RADIUS server implementations..."

  Or "RADIUS server implementations have traditionally provided support..."

> This
> model is not explicitly documented in the draft and unfortunately has
> implications on the design of attributes particularly when it comes to data
> types used by RADIUS attributes and for the claimed problems that arise from
> adding new code to the RADIUS server.  

  Even if an implementation can easily handle complex attributes defined
in a "dictionary", is there any *reason* to use complex attributes where
the standard data types would be sufficient?

  If not, then the existing text would seem to be sufficient.

> In previous mail exchanges on the list I did not agree with certain aspects
> of the implicitly assumed progressing model. I am, however, OK with
> documenting the model and to thereby make it explicit to the reader. The
> understanding of some of the claimed limitations might also be clearer.

  The draft explicitly mentions a *typical* data model implemented by a
RADIUS server.

  As for making the limitations clear, the document already does that.
It states that the data dictionary approach means that it allows:

   ... RADIUS servers to be configured to support new attributes
   without requiring server code changes.  ...

  Should we add some text here saying:

  "Some implementations can support more complex attributes defined in a
more complex dictionary than is traditional.  However, this document
does not recommend defining complex attributes for all of the reasons
outlined in Section 2.1.3"

  I fail to see how that will help.

  The text allows more complex implementations of dictionaries.  Nothing
in the text *forbids* more complex implementations of dictionaries.
Nothing in the text suggests that it is a good idea to use complex types
where standard types would suffice.  The document already discusses the
typical model, along with its limitations.

  So... why do we need to say any more?

  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: Thu, 03 Sep 2009 00:30:44 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 314:  My Problem
Date: Wed, 2 Sep 2009 17:30:27 -0700

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue 314: My Problem

Submitter name: Hannes Tschofenig  

Submitter email address: [email-masked]

Date first submitted:  May 9, 2009

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html

Document: 
Design-Guidelines 

Comment type: Technical 

Priority: S  

Section: Various  

Rationale/Explanation of issue:
The document assumes a certain implementation and processing model. This
model is not explicitly documented in the draft and unfortunately has
implications on the design of attributes particularly when it comes to data
types used by RADIUS attributes and for the claimed problems that arise from
adding new code to the RADIUS server. 

In previous mail exchanges on the list I did not agree with certain aspects
of the implicitly assumed progressing model. I am, however, OK with
documenting the model and to thereby make it explicit to the reader. The
understanding of some of the claimed limitations might also be clearer.
PS: FYI, I stated my concerns previously on the RADEXT list.

[Alan DeKok] Do you have suggested text for the document?
[Hannes] 
I can compile some text but this is not saying that I agree with the assumed
model, i.e. one where essentially no improvement in implementations was made
over the last 10 years. 
[David Nelson] 
Perhaps, but this seems to presume that data-dictionary-driven server
implementations are a liability which requires improvement.  Like a network
management application for SNMP which has the ability to "enroll" a MIB
module without code changes, a RADIUS server that can simply add new
attributes to its dictionary is a boon to users.

We can split hairs about what types of user-added executable scripts are or
are not "coding".  I still think that the data dictionary architecture is a
very powerful concept.  Not to mention a very widely deployed one.

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<strong>Issue 314: My Problem</strong><br>
Submitter name: Hannes Tschofenig&nbsp; <br>
Submitter email address: [email-masked]<br>
Date first submitted:&nbsp; May 9, 2009<br>
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html<br>
Document: 
Design-Guidelines 
<br>
Comment type: Technical <br>
Priority: S&nbsp; <br>
Section:&nbsp;Various&nbsp; <br>
Rationale/Explanation of issue:
<pre>The document assumes a certain implementation and processing model. This<br>model is not explicitly documented in the draft and unfortunately has<br>implications on the design of attributes particularly when it comes to data<br>types used by RADIUS attributes and for the claimed problems that arise from<br>adding new code to the RADIUS server. <br><br>In previous mail exchanges on the list I did not agree with certain aspects<br>of the implicitly assumed progressing model. I am, however, OK with<br>documenting the model and to thereby make it explicit to the reader. The<br>understanding of some of the claimed limitations might also be clearer.</pre>
<pre>PS: FYI, I stated my concerns previously on the RADEXT list.<br></pre>
<pre>[Alan DeKok] Do you have suggested text for the document?</pre>
<pre>[Hannes] </pre>
<pre>I can compile some text but this is not saying that I agree with the assumed<br>model, i.e. one where essentially no improvement in implementations was made<br>over the last 10 years. </pre>
<pre>[David Nelson] </pre>
<pre>Perhaps, but this seems to presume that data-dictionary-driven server<br>implementations are a liability which requires improvement.  Like a network<br>management application for SNMP which has the ability to "enroll" a MIB<br>module without code changes, a RADIUS server that can simply add new<br>attributes to its dictionary is a boon to users.<br><br>We can split hairs about what types of user-added executable scripts are or<br>are not "coding".  I still think that the data dictionary architecture is a<br>very powerful concept.  Not to mention a very widely deployed one.<br></pre><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_--

--
to unsubscribe send 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, 03 Sep 2009 00:27:19 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
Date: Wed, 2 Sep 2009 17:26:57 -0700

--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP", prior to sending this document on to the IESG for
publication as an Experimental RFC.  The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

The original RADEXT
WG last call lasted until August 7, 2009, but no comments were received.  We will therefore extend the comment period until October 2, 2009. Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/

--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP", prior to sending this document on to the IESG for
publication as an Experimental RFC.&nbsp; The document is available for
inspection here:<br>
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport<br>
<br>
The original RADEXT
WG last call lasted until August 7, 2009, but no comments were received.&nbsp; We will therefore extend the comment period until October 2, 2009. Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/<br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_b155f041-0060-4939-8440-679293bec851_--

--
to unsubscribe send 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, 03 Sep 2009 00:18:38 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 2 Sep 2009 17:18:15 -0700

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a reminder of the ongoing call for review of the document "DTLS as a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.  This document is
being targeted at Experimental
status. 

The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls

The original call for review expired August 7, 2009, but no comments were received.  This call for input will last until October 2, 2009.  Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.  If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of the ongoing call for review of the document "DTLS as a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.&nbsp; This document is
being targeted at Experimental
status. <br>
&nbsp;<br>The document is available for review here:<br><span style="font-size: 10pt; color: rgb(0, 104, 207); font-family: 'Verdana','sans-serif';"></span>http://tools.ietf.org/html/draft-dekok-radext-dtls<br><br>The original call for review expired August 7, 2009, but no comments were received.&nbsp; This call for input will last until October 2, 2009.&nbsp; Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.&nbsp; If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:<br><a rel="nofollow" href="http://www.drizzle.com/%7Eaboba/RADEXT/" target="_blank"><font color="#0068cf">http://www.drizzle.com/~aboba/RADEXT/</font></a><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a></td></tr></tbody></table></body>
</html>
--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_--

--
to unsubscribe send 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, 02 Sep 2009 23:58:10 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 313:  Security Exemption
Date: Wed, 2 Sep 2009 16:57:42 -0700

--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HTML clipboardIssue 313: Security Exemption

Submitter name: Alan DeKok  

Submitter email address:  [email-masked]

Date first submitted: July 24, 2009  

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html

Document: 
Design Guidelines

Comment type: Technical 

Priority: S  

Section:  A.2.1

Rationale/Explanation of issue:

Section A.2.1 states:

      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security, as described below in Section
        A.2.2.
Should this exemption be removed and/or clarified?
[email-masked] wrote:
> Yeah.  I've always been a bit uncomfortable with the "security
> functionality" escape clause in the RADIUS Design Guidelines draft. 
> Lots of things can reasonably be claimed to be "security related".  I
> would have preferred the exception to be crafted a bit narrower, just
> for this reason.  But, unless wording of Design Guidelines is changed,
> you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int, IP address, etc.), or they are "opaque data" that RADIUS is
simply transporting on the behalf of the other protocol.
Proposed Resolution: Discuss

 EMAILING FOR THE GREATER GOOD
Join me
--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<title>HTML clipboard</title><meta content="MSHTML 6.00.2900.2876" name="GENERATOR"><meta content="FrontPage.Editor.Document" name="ProgId"><style>LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""
}
DIV.Section1 {
	page: Section1
}
.style7 {
	font-size: 10.5pt;
	font-family: Consolas;
	margin-left: 0in;
	margin-right: 0in;
	margin-top: 0in;
	margin-bottom: .0001pt;
}
</style><strong>Issue 313: Security Exemption</strong><br>
Submitter name: Alan DeKok&nbsp; <br>
Submitter email address:&nbsp; [email-masked]<br>
Date first submitted: July 24, 2009&nbsp; <br>
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html<br>
Document: 
Design Guidelines<br>
Comment type: Technical <br>
Priority: S&nbsp; <br>
Section:&nbsp;&nbsp;A.2.1<br>
Rationale/Explanation of issue:<BR>
Section A.2.1 states:<BR>
<pre class="newpage">      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [<a title="&quot;Extended Remote Authentication Dial In User Service (RADIUS) Attributes&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-design-07#ref-EXTEN">EXTEN</a>] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security, as described below in Section
        A.2.2.</pre>
<pre class="newpage">Should this exemption be removed and/or clarified?</pre>
<pre>[email-masked] wrote:
&gt; Yeah.  I've always been a bit uncomfortable with the "security
&gt; functionality" escape clause in the RADIUS Design Guidelines draft. 
&gt; Lots of things can reasonably be claimed to be "security related".  I
&gt; would have preferred the exception to be crafted a bit narrower, just
&gt; for this reason.  But, unless wording of Design Guidelines is changed,
&gt; you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int, IP address, etc.), or they are "opaque data" that RADIUS is
simply transporting on the behalf of the other protocol.</pre>
<tt><i><strong>Proposed Resolution: Discuss</strong></i></tt><BR>
<br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_--

--
to unsubscribe send 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, 02 Sep 2009 23:52:08 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 312:  Normative Reference to Extended Attributes Document
Date: Wed, 2 Sep 2009 16:51:45 -0700

--_73b09e04-e9be-410b-b709-1f5ee1f52453_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HTML clipboardIssue 312: Normative Reference to Extended Attributes Document

Submitter name: Bernard Aboba  

Submitter email address: [email-masked] 

Date first submitted: July 31, 2009  

Reference: 

Document: 
Design-Guidelines 

Comment type: Editorial 

Priority: S  

Section: 2.2, 3, 6.1  

Rationale/Explanation of issue:

In Section 2.2 and 3 the Design Guidelines document contains normative 
language relating to the Extended Attributes document.  This has resulted 
in a normative dependency on that document.  Given that the Extended 
Attributes document is not yet completed, and can contain its own usage 
guidelines, is the normative reference appropriate? 

2.2. Extended RADIUS Attributes
The extended RADIUS attribute document [EXTEN] 
defines a number of extensions to RADIUS. The standard attribute space is 
extended by permitting standard allocations from within a specific subset of the 
VSA space; the format of extended attributes is defined; and extended data types 
are defined within that format. New specifications seeking to extend the 
standard RADIUS data model SHOULD examine [EXTEN] 
to see if their needs fit within the extended RADIUS data model.From Section 
3: 

   Recent extensions to the RADIUS data model such as [EXTEN] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.
Proposed Resolution: Discuss

 EMAILING FOR THE GREATER GOOD
Join me
--_73b09e04-e9be-410b-b709-1f5ee1f52453_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<title>HTML clipboard</title><meta content="MSHTML 6.00.2900.2876" name="GENERATOR"><meta content="FrontPage.Editor.Document" name="ProgId"><style>LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""
}
DIV.Section1 {
	page: Section1
}
.style7 {
	font-size: 10.5pt;
	font-family: Consolas;
	margin-left: 0in;
	margin-right: 0in;
	margin-top: 0in;
	margin-bottom: .0001pt;
}
</style><strong>Issue 312: Normative Reference to Extended Attributes Document</strong><br>
Submitter name: Bernard Aboba&nbsp; <br>
Submitter email address: [email-masked] <br>
Date first submitted: July 31, 2009&nbsp; <br>
Reference:&nbsp;
<br>
Document: 
Design-Guidelines 
<br>
Comment type: Editorial <br>
Priority: S&nbsp; <br>
Section:&nbsp;2.2, 3, 6.1&nbsp; <br>
Rationale/Explanation of issue:<BR>
In Section 2.2 and 3 the Design Guidelines document contains normative 
language relating to the Extended Attributes document.&nbsp; This has resulted 
in a normative dependency on that document.&nbsp; Given that the Extended 
Attributes document is not yet completed, and can contain its own usage 
guidelines, is the normative reference appropriate? <BR>
<span class="h3">
<h3><a name="section-2.4">2.2</a>. Extended RADIUS Attributes</h3>
</span>The extended RADIUS attribute document [<a title="&quot;Extended Remote Authentication Dial In User Service (RADIUS) Attributes&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-design-07#ref-EXTEN">EXTEN</a>] 
defines a number of extensions to RADIUS. The standard attribute space is 
extended by permitting standard allocations from within a specific subset of the 
VSA space; the format of extended attributes is defined; and extended data types 
are defined within that format. New specifications seeking to extend the 
standard RADIUS data model SHOULD examine [<a title="&quot;Extended Remote Authentication Dial In User Service (RADIUS) Attributes&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-design-07#ref-EXTEN">EXTEN</a>] 
to see if their needs fit within the extended RADIUS data model.From Section 
3: <BR>
<pre class="newpage">   Recent extensions to the RADIUS data model such as [<a title="&quot;Extended Remote Authentication Dial In User Service (RADIUS) Attributes&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-design-07#ref-EXTEN">EXTEN</a>] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [<a title="&quot;Extended Remote Authentication Dial In User Service (RADIUS) Attributes&quot;" href="http://tools.ietf.org/html/draft-ietf-radext-design-07#ref-EXTEN">EXTEN</a>] to see if their needs fit within the extended
   RADIUS data model.</pre>
<tt><i><strong>Proposed Resolution: Discuss</strong></i></tt><BR>
<br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_73b09e04-e9be-410b-b709-1f5ee1f52453_--

--
to unsubscribe send 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, 02 Sep 2009 23:41:27 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Issue 311: IESG DISCUSS comments
Date: Wed, 2 Sep 2009 16:40:58 -0700

--_8907f3f2-4237-48ff-a215-48719ee1fd80_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HTML clipboardIssue 311: IESG DISCUSS comments

Submitter name: Jari Arkko  

Submitter email address: [email-masked] 

Date first submitted:   May 7, 2009

Reference:
https://datatracker.ietf.org/idtracker/ballot/2883/

Document: 
Design-Guidelines 

Comment type: Technical 

Priority: S  

Section: Various

Rationale/Explanation of issue:

Jari Arkko:

Discuss [2009-05-07]:
Great doc! I will vote Yes on it, but I wanted to discuss two issues
first, one is a Discuss-level problem and the other one a Comment that
I'd like you to consider.
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.

There are a couple of problems with this. First, if you really mean
to change the recommendation, then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.

Secondly, while I agree with the advice of going for 16 bits, the
document is silent on some of the issues involved in such a change,
such as:

- Does RADIUS dictionary software support the VSA format for 16 bits, 8
  bits, or both?

- How do you cleanly print or report VSAs when you do not know if the
  field size is 8 or 16 bits? I realize that this situation already
  exists since the format was never required to be followed, but
  your new recommendation makes a potential problem much more likely
  to appear. Previously, you could print something like Vendor = ACME,
  Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

- Can a vendor who moved from 8 bits to 16 bits deal with this?

Comment [2009-05-07]:
I do agree that for functionality FOO, both the functionality itself
and the MIB, RADIUS, etc. work should take place in the same standards
body. However, Section 3.1 could have said a couple of additional things
as well:

The issues of attribute space and choice of forum are distinct; there
is no reason why IETF couldn't use its own vendor code, for instance.

The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem, as opposed to finding
a common solution.

Ralph Droms:

Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte?  I ask because
there has been confusion about this point in DHCP options and it might be good
to make the convention explicit.

Lars Eggert:

Comment [2009-04-20]:

Section 2.1.1, paragraph 2:
>    The Length field in the RADIUS packet header is defined in [RFC2865]
>    Section 3.  It is noted there that the maximum length of a RADIUS
>    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
>    assume that a RADIUS implementation can successfully process RADIUS
>    packets larger than 4096 octets.

  You may want to point out that even with messages less than 4096 but
  larger than the PMTU, persistent IP fragmentation will be incurred,
  which makes communication much more brittle, and might even want to
  suggest that therefore RADIUS messages should be kept as small as
  possible. See RFC5405 Section 3.2.

Adrian Farrel:

Comment [2009-04-18]:
Trivial, but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a reason
for this difference?

I wonder if the text in seciton 4 should be stronger. You have...

   This document does not require that the IANA update any existing
   registry or create any new registry, but includes information that
   affects the IANA, for example:

      * includes guidelines that recommend against allocation from the
        RADIUS standard attribute space in other SDO RADIUS Attribute
        specifications.

But, in fact, IANA are bound by the registry rules already laid down and cannot
make allocations except following IETF process as defined by RFC 3575.

Russ Housley:

Comment [2009-04-20]:

  The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
  editorial suggestions.

  ID nits complains that reference [8] appears in Appendix B.6 but not
  in the References.

  The Introduction Section should be a non-normative section. However,
  Section 1.1 uses normative statements (RECOMMENDED and NOT
  RECOMMENDED) before those terms are defined in Section 1.3.

  The acronym AAA should be expanded.

  When referring to the appendixes, I think the draft should talk about
  appendixes, not about sections. For example, it should talk about
  Appendix A.5, not about Section A.5.

Alexey Melnikov:

Comment [2009-04-21]:
This is a fine document. Some minor comments:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless;
      * Provisioning of services is not possible within an
        Access-Reject;
      * Distinction between authorization checks and user
        authentication;
      * Authentication and integrity protection of RADIUS packets;
      * The RADIUS protocol is a Request/Response protocol.
      * Packet length restriction.

Half of this list is comprised from full sentences, the other half is not. I
would appreciate if you can make this consistent, otherwise it
is difficult to read/understand.

Tim Polk:

Comment [2009-05-06]:
It might be valuable to supplement the current security considerations section
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example, relying on MTU discovery to support transporting
large amounts of data could fail and result in denial of service, lost
accounting data, etc...

Robert Sparks:

Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
Proposed Resolution: Discuss

 EMAILING FOR THE GREATER GOOD
Join me
--_8907f3f2-4237-48ff-a215-48719ee1fd80_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<title>HTML clipboard</title><meta content="MSHTML 6.00.2900.2876" name="GENERATOR"><meta content="FrontPage.Editor.Document" name="ProgId"><style>LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""
}
DIV.Section1 {
	page: Section1
}
.style7 {
	font-size: 10.5pt;
	font-family: Consolas;
	margin-left: 0in;
	margin-right: 0in;
	margin-top: 0in;
	margin-bottom: .0001pt;
}
</style><strong>Issue 311: IESG DISCUSS comments</strong><br>
Submitter name: Jari Arkko&nbsp; <br>
Submitter email address: [email-masked] <br>
Date first submitted: &nbsp; May 7, 2009<br>
Reference:
https://datatracker.ietf.org/idtracker/ballot/2883/<br>
Document: 
Design-Guidelines 
<br>
Comment type: Technical <br>
Priority: S&nbsp; <br>
Section:&nbsp;Various<br>
Rationale/Explanation of issue:<BR>
<pre>Jari Arkko:

Discuss [2009-05-07]:
Great doc! I will vote Yes on it, but I wanted to discuss two issues
first, one is a Discuss-level problem and the other one a Comment that
I'd like you to consider.</pre>
<pre>The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.

There are a couple of problems with this. First, if you really mean
to change the recommendation, then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.

Secondly, while I agree with the advice of going for 16 bits, the
document is silent on some of the issues involved in such a change,
such as:

- Does RADIUS dictionary software support the VSA format for 16 bits, 8
  bits, or both?

- How do you cleanly print or report VSAs when you do not know if the
  field size is 8 or 16 bits? I realize that this situation already
  exists since the format was never required to be followed, but
  your new recommendation makes a potential problem much more likely
  to appear. Previously, you could print something like Vendor = ACME,
  Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

- Can a vendor who moved from 8 bits to 16 bits deal with this?

Comment [2009-05-07]:
I do agree that for functionality FOO, both the functionality itself
and the MIB, RADIUS, etc. work should take place in the same standards
body. However, Section 3.1 could have said a couple of additional things
as well:

The issues of attribute space and choice of forum are distinct; there
is no reason why IETF couldn't use its own vendor code, for instance.

The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem, as opposed to finding
a common solution.

Ralph Droms:

Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte?  I ask because
there has been confusion about this point in DHCP options and it might be good
to make the convention explicit.

Lars Eggert:

Comment [2009-04-20]:

Section 2.1.1, paragraph 2:
&gt;    The Length field in the RADIUS packet header is defined in [RFC2865]
&gt;    Section 3.  It is noted there that the maximum length of a RADIUS
&gt;    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
&gt;    assume that a RADIUS implementation can successfully process RADIUS
&gt;    packets larger than 4096 octets.

  You may want to point out that even with messages less than 4096 but
  larger than the PMTU, persistent IP fragmentation will be incurred,
  which makes communication much more brittle, and might even want to
  suggest that therefore RADIUS messages should be kept as small as
  possible. See RFC5405 Section 3.2.

Adrian Farrel:

Comment [2009-04-18]:
Trivial, but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a reason
for this difference?

I wonder if the text in seciton 4 should be stronger. You have...

   This document does not require that the IANA update any existing
   registry or create any new registry, but includes information that
   affects the IANA, for example:

      * includes guidelines that recommend against allocation from the
        RADIUS standard attribute space in other SDO RADIUS Attribute
        specifications.

But, in fact, IANA are bound by the registry rules already laid down and cannot
make allocations except following IETF process as defined by RFC 3575.

Russ Housley:

Comment [2009-04-20]:

  The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
  editorial suggestions.

  ID nits complains that reference [8] appears in Appendix B.6 but not
  in the References.

  The Introduction Section should be a non-normative section. However,
  Section 1.1 uses normative statements (RECOMMENDED and NOT
  RECOMMENDED) before those terms are defined in Section 1.3.

  The acronym AAA should be expanded.

  When referring to the appendixes, I think the draft should talk about
  appendixes, not about sections. For example, it should talk about
  Appendix A.5, not about Section A.5.

Alexey Melnikov:

Comment [2009-04-21]:
This is a fine document. Some minor comments:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless;
      * Provisioning of services is not possible within an
        Access-Reject;
      * Distinction between authorization checks and user
        authentication;
      * Authentication and integrity protection of RADIUS packets;
      * The RADIUS protocol is a Request/Response protocol.
      * Packet length restriction.

Half of this list is comprised from full sentences, the other half is not. I
would appreciate if you can make this consistent, otherwise it
is difficult to read/understand.

Tim Polk:

Comment [2009-05-06]:
It might be valuable to supplement the current security considerations section
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example, relying on MTU discovery to support transporting
large amounts of data could fail and result in denial of service, lost
accounting data, etc...

Robert Sparks:

Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.</pre>
<tt><i><strong>Proposed Resolution: Discuss</strong></i></tt><BR>
<br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_8907f3f2-4237-48ff-a215-48719ee1fd80_--

--
to unsubscribe send 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, 02 Sep 2009 22:54:08 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 15:53:26 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0180_01CA2BE5.88000BD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The RADEXT WG will be having a virtual interim meeting in early October.  

Why?

Potential dates include:

* Thursday, October 8
* Monday, October 12
* Tuesday, October 13
* Wednesday, October 14

To fill in your preferences for dates and times, please fill in the
following Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg

------=_NextPart_000_0180_01CA2BE5.88000BD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>The RADEXT WG will be having a virtual
interim meeting in early October.&nbsp; <span style='color:#1F497D'><o:p></o:p></span></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Arial Black","sans-serif";color:#1F497D'>Why?<o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>Potential dates include:<br>
<br>
* Thursday, October 8<br>
* Monday, October 12<br>
* Tuesday, October 13<br>
* Wednesday, October 14<br>
<br>
To fill in your preferences for dates and times, please fill in the following
Doodle poll:<br>
https://www.doodle.com/74uz2b233eu2vseg<br>
<br>
<br>
<br>
<o:p></o:p></span></p>

<table class=MsoNormalTable border=1 cellpadding=0 style='border:none;
 border-top:solid black 1.0pt'>
 <tr>
  <td style='border:none;padding:.75pt .75pt .75pt .75pt'></td>
 </tr>
</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0180_01CA2BE5.88000BD0--

--
to unsubscribe send 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, 02 Sep 2009 21:37:50 +0000
Date: Wed, 2 Sep 2009 21:37:11 +0000 (GMT)
From: David Mitton <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times

Thanks,
    I had the same question.  and FYI:  Oct 12th is Columbus Day, or 
   according to my calendar, Thanksgiving Day in Canada.

Dave.

Sep 2, 2009 12:38:30 PM, [email-masked] wrote:

Assumed time zone is PDT. 

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
> Date: Wed, 2 Sep 2009 12:10:45 -0400
> 
> > To fill in your preferences for dates and times, please fill
> > in the following Doodle poll:
> > https://www.doodle.com/74uz2b233eu2vseg
> 
> What is the assumed time zone for the times listed at the top of the poll
> matrix?
> 
> 

--
to unsubscribe send 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, 02 Sep 2009 16:34:43 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 09:34:18 -0700

--_a221acec-455c-432f-8c29-bd90c10de88b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Assumed time zone is PDT. 

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
> Date: Wed, 2 Sep 2009 12:10:45 -0400
> 
> > To fill in your preferences for dates and times, please fill
> > in the following Doodle poll:
> > https://www.doodle.com/74uz2b233eu2vseg
> 
> What is the assumed time zone for the times listed at the top of the poll
> matrix?
> 
> 

--_a221acec-455c-432f-8c29-bd90c10de88b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Assumed time zone is PDT. <br><br>&gt; From: [email-masked]<br>&gt; To: [email-masked]; [email-masked]<br>&gt; Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times<br>&gt; Date: Wed, 2 Sep 2009 12:10:45 -0400<br>&gt; <br>&gt; &gt; To fill in your preferences for dates and times, please fill<br>&gt; &gt; in the following Doodle poll:<br>&gt; &gt; https://www.doodle.com/74uz2b233eu2vseg<br>&gt; <br>&gt; What is the assumed time zone for the times listed at the top of the poll<br>&gt; matrix?<br>&gt; <br>&gt; <br></body>
</html>
--_a221acec-455c-432f-8c29-bd90c10de88b_--

--
to unsubscribe send 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, 02 Sep 2009 16:11:27 +0000
From: "Dave Nelson" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 12:10:45 -0400

> To fill in your preferences for dates and times, please fill
> in the following Doodle poll:
> https://www.doodle.com/74uz2b233eu2vseg

What is the assumed time zone for the times listed at the top of the poll
matrix?

--
to unsubscribe send 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, 02 Sep 2009 08:33:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 10:32:16 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA2BA7.E15232AA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bernard,
 
What time zone? 
 
Dan

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Tuesday, September 01, 2009 10:38 PM
	To: [email-masked]
	Subject: Action Requested: RADEXT WG Virtual Interim Meeting
Dates, Times

	The RADEXT WG will be having a virtual interim meeting in early
October.  Potential dates include:
	
	* Thursday, October 8
	* Monday, October 12
	* Tuesday, October 13
	* Wednesday, October 14
	
	To fill in your preferences for dates and times, please fill in
the following Doodle poll:
	https://www.doodle.com/74uz2b233eu2vseg

<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 

------_=_NextPart_001_01CA2BA7.E15232AA
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=Content-Type content="text/html; charset=us-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Verdana
}
</STYLE>

<META content="MSHTML 6.00.2900.3603" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV><SPAN class=410333108-02092009><FONT face=Arial 
color=#0000ff>Bernard,</FONT></SPAN></DIV>
<DIV><SPAN class=410333108-02092009><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=410333108-02092009><FONT face=Arial color=#0000ff>What time 
zone? </FONT></SPAN></DIV>
<DIV><SPAN class=410333108-02092009></SPAN><SPAN class=410333108-02092009><FONT 
face=Arial color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=410333108-02092009><FONT face=Arial 
color=#0000ff>Dan</FONT></SPAN></DIV>
<DIV><SPAN class=410333108-02092009><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of </B>Bernard 
  Aboba<BR><B>Sent:</B> Tuesday, September 01, 2009 10:38 PM<BR><B>To:</B> 
  [email-masked]<BR><B>Subject:</B> Action Requested: RADEXT WG Virtual 
  Interim Meeting Dates, Times<BR></FONT><BR></DIV>
  <DIV></DIV>The RADEXT WG will be having a virtual interim meeting in early 
  October.&nbsp; Potential dates include:<BR><BR>* Thursday, October 8<BR>* 
  Monday, October 12<BR>* Tuesday, October 13<BR>* Wednesday, October 
  14<BR><BR>To fill in your preferences for dates and times, please fill in the 
  following Doodle 
  poll:<BR>https://www.doodle.com/74uz2b233eu2vseg<BR><BR><BR><BR><BR>
  <TABLE 
  style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
    <TBODY>
    <TR>
      <TD><A 
        style="FONT-SIZE: 9pt; COLOR: rgb(1,132,203); TEXT-DECORATION: none" 
        href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><SPAN 
        style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: rgb(63,181,85); PADDING-TOP: 0px; TEXT-DECORATION: underline"></SPAN></A><BR></TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01CA2BA7.E15232AA--

--
to unsubscribe send 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, 01 Sep 2009 19:40:11 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Call for Agenda items for RADEXT Virtual Interim Meeting
Date: Tue, 1 Sep 2009 12:40:02 -0700

--_73ada233-4a27-4935-9124-88c11b65da6e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a call for agenda items for the RADEXT Virtual Interim Meeting.  If you'd like to get on the agenda, please send email to David or myself. 

--_73ada233-4a27-4935-9124-88c11b65da6e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a call for agenda items for the RADEXT Virtual Interim Meeting.&nbsp; If you'd like to get on the agenda, please send email to David or myself. <br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_73ada233-4a27-4935-9124-88c11b65da6e_--

--
to unsubscribe send 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, 01 Sep 2009 19:38:54 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Tue, 1 Sep 2009 12:38:07 -0700

--_a642a527-345e-4fb0-803f-1bf85e389167_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT WG will be having a virtual interim meeting in early October.  Potential dates include:

* Thursday, October 8
* Monday, October 12
* Tuesday, October 13
* Wednesday, October 14

To fill in your preferences for dates and times, please fill in the following Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg

--_a642a527-345e-4fb0-803f-1bf85e389167_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The RADEXT WG will be having a virtual interim meeting in early October.&nbsp; Potential dates include:<br><br>* Thursday, October 8<br>* Monday, October 12<br>* Tuesday, October 13<br>* Wednesday, October 14<br><br>To fill in your preferences for dates and times, please fill in the following Doodle poll:<br>https://www.doodle.com/74uz2b233eu2vseg<br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_a642a527-345e-4fb0-803f-1bf85e389167_--

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