Subject: "Last Look" at the RADIUS Design Guidelines document

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 4 Dec 2009 07:22:30 -0800

This is announcing a "Last Look" at the RADIUS Design Guidelines document.
This "Last Look" will last until 

Friday, December 18, 2009.  

Since the Design Guidelines document has already completed RADEXT WG last
call (twice), IETF last call,

and IESG review (no outstanding DISCUSS comments), the purpose of this "Last
Look" is to confirm that

all Issues brought up in IETF last call and the IESG Issues list (as noted
in Draft Tracker) have been resolved. 

The document is available here:

http://www.ietf.org/id/draft-ietf-radext-design-10.txt

Please send comments relating to the document to the RADEXT WG mailing list
([email-masked]). 

As usual, if you are submitting Issues, please utilize the Issue format
described in the RADIUS WG

Issue list (http://www.drizzle.com/~aboba/RADEXT )

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 18 Dec 2009 20:17:45 -0800

I gave the RADIUS Design Guidelines document a "last look".  I had not
looked at the document for a while and have not really been following
discussions on the document.  In general I think the document provides
some useful information.  There are a few places where I had issues with
the document.  I'm not sure if these are part of the IESG and Last call
comments or not.  

A. Section 2.1.3  

I did not find the discussion of complex attributes very compelling.
Its not clear to me what the difference between string and complex
attribute is.  If your RADIUS server supports string then it seems that
it would be possible to support a complex attribute without requiring a
"code change".  

B. Section 2.1.4

I'm not really sure what this section is trying to accomplish.  It seems
to be a lot about deployment guidelines instead of design guidelines.
I'm also not convinced that the use of complex attributes makes things
less secure.  It does not seem this section belongs in this document. 

C. Section 5

This section references section 2.1.4, however it does not seem there is
anything actionable for a protocol document to do with section 2.1.4. 

D. Section A.2.2

Since I did not agree with the motivation for section 2.1.3, I don't
find this section compelling. 

E. Section A.2.1

I don't see how defining a polymorphic attribute as multiple attributes
helps.  I'm probably missing something, do you have an example? 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, December 04, 2009 7:23 AM
> To: [email-masked]
> Subject: "Last Look" at the RADIUS Design Guidelines document
> 
> This is announcing a "Last Look" at the RADIUS Design 
> Guidelines document.  This "Last Look" will last until 
> 
> Since the Design Guidelines document has already completed 
> RADEXT WG last call (twice), IETF last call,
> 
> and IESG review (no outstanding DISCUSS comments), the 
> purpose of this "Last Look" is to confirm that
> 
> all Issues brought up in IETF last call and the IESG Issues 
> list (as noted in Draft Tracker) have been resolved. 
> 
>  
> 
> Please send comments relating to the document to the RADEXT 
> WG mailing list ([email-masked]). 
> 
> As usual, if you are submitting Issues, please utilize the 
> Issue format described in the RADIUS WG
> 

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

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Dec 2009 08:49:05 +0100

> it would be possible to support a complex attribute without requiring a

  It depends on what you mean by "support".

  There is no question that a RADIUS server can *transport* any complex
attribute if the attribute is treated as type "string".  However, having
the RADIUS server parse that attribute requires much more work.

  Perhaps a better argument is to ask "why?".  i.e. Why is a data
structure being sent when the contents could have been broken out into
separate attributes with standard data types?

  The document tries to suggest that where possible, complex attributes
should be replaced by attributes with standard data types.  Where that
is not possible, complex attributes could be used.

> less secure.  It does not seem this section belongs in this document. 

  Using complex attributes does not make things less secure.  *Code
changes* make things less secure.

  The intent of this section is to explain some of the reasons behind
the recommendations, rather than to have them appear out of thin air.

> anything actionable for a protocol document to do with section 2.1.4. 

  I think the reference should be to 2.1.3.

> find this section compelling. 

  This is one point where I strongly disagree.  It can be summarized as
"keep things simple".

  Would you counter this section by suggesting it's a *good* idea to
have complex attributes, where standard ones would do just as well?  If
so, why?

> helps.  I'm probably missing something, do you have an example? 

 See Section 3.2 for a larger explanation.  In short:

- Attribute X means "integer", unless there is another attribute Y in
the packet, in which case Attribute X means "mac address"

  Both the size and contents of the attribute changes.  There's really
no good reason.  Instead, two standard attributes can be used, with no
magical meanings.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 20 Dec 2009 21:31:44 -0800

> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Friday, December 18, 2009 11:49 PM
> To: Joseph Salowey (jsalowey)
> Cc: Bernard Aboba; [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> > attribute is.  If your RADIUS server supports string then it seems 
> > that it would be possible to support a complex attribute without 
> > requiring a "code change".
> 
>   There is no question that a RADIUS server can *transport* 
> any complex attribute if the attribute is treated as type 
> "string".  However, having the RADIUS server parse that 
> attribute requires much more work.
> 
[Joe] It seems a type "string" attribute would have the same parsing
requirement.    

>   Perhaps a better argument is to ask "why?".  i.e. Why is a 
> data structure being sent when the contents could have been 
> broken out into separate attributes with standard data types?
> 
[Joe] To me it seems like you are just pushing the problem around.  If
the RADIUS server doesn't have to validate or parse the attribute then
it doesn't make a difference.  If the RADIUS server does need to process
it then you need code to do the validation and parsing across several
basic attributes.    

>   The document tries to suggest that where possible, complex 
> attributes should be replaced by attributes with standard 
> data types.  Where that is not possible, complex attributes 
> could be used.
>
> > B. Section 2.1.4
> > 
> > I'm not really sure what this section is trying to accomplish.  It 
> > seems to be a lot about deployment guidelines instead of 
> design guidelines.
[Joe] Complex attributes don't always require code changes and if you
are adding several new basic attributes that need to be validated
together then you need code to do that. 

>   The intent of this section is to explain some of the 
> reasons behind the recommendations, rather than to have them 
> appear out of thin air.
> 
> > C. Section 5
> > 
> > This section references section 2.1.4, however it does not 
> seem there 
> > is anything actionable for a protocol document to do with 
> section 2.1.4.
> 
[Joe] OK, I think that makes more sense. 

>   This is one point where I strongly disagree.  It can be 
> summarized as "keep things simple".
> 
>   Would you counter this section by suggesting it's a *good* 
> idea to have complex attributes, where standard ones would do 
> just as well?  If so, why?
> 
[Joe] That does not seem to be what section A.2.2 states.  It talks
about whether attributes need dynamic computation or not.  It seems the
second and third bullet outlaw all cases, since the first covers dynamic
computation and the second covers static attributes.  

> > E. Section A.2.1
> > 
> > I don't see how defining a polymorphic attribute as multiple 
> > attributes helps.  I'm probably missing something, do you 
> have an example?
> 
> - Attribute X means "integer", unless there is another 
> attribute Y in the packet, in which case Attribute X means 
> "mac address"
> 
>   Both the size and contents of the attribute changes.  
> There's really no good reason.  Instead, two standard 
> attributes can be used, with no magical meanings.
> 
[Joe] OK, got it.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 20 Dec 2009 23:43:11 -0800

> it would be possible to support a complex attribute without requiring a

There are several distinct aspects that are discussed in Section 2.1.3:

a. Enabling a RADIUS server to send a complex attribute;
b. Enabling a RADIUS server to receive a complex attribute; 
c. Enabling a RADIUS client to send a complex attribute;
d. Enabling a RADIUS client to receive a complex attribute. 

However, rather than examining each of these aspects separately, the section
appears to switch between the aspects, sometimes within the same paragraph. 
As a result, it is not always clear what aspects are being discussed.  Since the
arguments made depend on what aspect is being discussed, it can be hard to
follow. 

For example, the second paragraph of Section 2.1.3 seems to focus largely on a).  As you say,
in this case, a RADIUS server can send a complex attribute without a code change 
(merely by encoding it as a string).  

However, while the first bullet appears to apply to aspect a) (e.g. ease of data entry), 
the second and third bullets appear to relate either to aspect b) or d).  

On reading the second and third bullets, I'm not sure which aspect is being referred to. 
In paragraph 4, it is noted that RADIUS clients require code changes to support any 
attribute, regardless of whether it is complex or not.   Therefore one cannot make
an argument about additional code changes arising from aspect c) or d), only 
aspect b). 

Presumably, with respect to aspect d), a RADIUS client receiving a complex attribute 
would also implement the required parsing and validation routes for that 
attribute (if not, then the client would either ignore the attribute, or possibly reject the 
Access-Response).   So on reading this, I'm not sure that the "additional error checking"
applies to, exactly. 

In reading paragraph 3 about server code changes, there does not appear to be a
distinction between aspect a (in which code changes are not required) and aspect b
(in which a code change would be necessary).  

Paragraph 4 does make the distinction between aspects c and d. 

However, paragraph 6 mixes aspects a) and b).  Paragraph 4 seems to assert that code
changes are not required for aspect a), while this paragraph does seem to say
that this is possible, though it is not clear in what circumstances this would be
necessary.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 20 Dec 2009 23:56:34 -0800

> less secure.  It does not seem this section belongs in this document. 

I think this section is trying to make a point relating to the security
properties of complex or opaque attributes, particularly in the case of
attributes sent from the RADIUS client to server.  

However, it occurs to me that the security risks depend quite a bit
on how the complex or opaque attribute is structured.  An "opaque" attribute that 
contains complex structures such as ASN.1 or XML would represent
a considerably larger security risk than say, a complex attribute 
including multiple 32-bit fields. 

It also occurs to me that some of the same security risks could be
present in simple attributes.  For example, even though a "string"
attribute might be widely implemented, if an attribute incorporates
a new concatenation mechanism, then such an attribute might
introduce a buffer-overun vulnerability that would be unlikely
to occur in the case of a complex attribute consisting of fixed fields.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Dec 2009 09:13:11 +0100

> [Joe] It seems a type "string" attribute would have the same parsing

  If the RADIUS server needs to understand it, and it carries a complex
data type.

  e.g. There are no parsing requirements for the Proxy-State attribute.
 It is a "string" attribute, but the contents are treated as an opaque
blob by proxies and clients.

> it then you need code to do the validation and parsing across several

  Partly.  The validation and parsing of the basic data types has
already been done.  Any additional validation and parsing is not needed
at the RADIUS attribute level.  Instead, it is needed to ensure that the
right set of attributes is sent and/or received.

> together then you need code to do that. 

  Of course.

> computation and the second covers static attributes.  

  I think you have the bullet references wrong... but I understand your
point.

  However, the section is trying to say:

a) re-using existing complex types is likely OK

b) creating new complex types for security is likely OK

c) transporting complex types that can be ignored RADIUS is likely OK
   (e.g. EAP-Message)

d) If the complex type can be instead be replaced by multiple attributes
   of the basic types, this is the preferred approach

e) Anything else is likely not a good use of RADIUS

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Dec 2009 09:19:04 +0100

Bernard Aboba wrote:
> a new concatenation mechanism,

  Then it involves changes to the basic operating model of RADIUS, where
attributes are independent.  This requires code changes, and all that
implies.

  Alan DeKok.

Delivery-date: Mon, 21 Dec 2009 08:19:29 +0000
Date: Mon, 21 Dec 2009 09:19:04 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Bernard Aboba wrote:
> a new concatenation mechanism,

  Then it involves changes to the basic operating model of RADIUS, where
attributes are independent.  This requires code changes, and all that
implies.

  Alan DeKok.

Delivery-date: Mon, 21 Dec 2009 08:13:43 +0000
Date: Mon, 21 Dec 2009 09:13:11 +0100
From: Alan DeKok <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

  Of course.

  Alan DeKok.

Delivery-date: Mon, 21 Dec 2009 07:57:09 +0000
From: Bernard Aboba <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 20 Dec 2009 23:56:34 -0800

--_6666a5ed-cc32-42ea-933d-c9eaa80ea201_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>=20
> less secure.  It does not seem this section belongs in this document.=20

I think this section is trying to make a point relating to the security
properties of complex or opaque attributes=2C particularly in the case of
attributes sent from the RADIUS client to server. =20

However=2C it occurs to me that the security risks depend quite a bit
on how the complex or opaque attribute is structured.  An "opaque" attribut=
e that=20
contains complex structures such as ASN.1 or XML would represent
a considerably larger security risk than say=2C a complex attribute=20
including multiple 32-bit fields.=20

It also occurs to me that some of the same security risks could be
present in simple attributes.  For example=2C even though a "string"
attribute might be widely implemented=2C if an attribute incorporates
a new concatenation mechanism=2C then such an attribute might
introduce a buffer-overun vulnerability that would be unlikely
to occur in the case of a complex attribute consisting of fixed fields.=20

 		 	   		  =

--_6666a5ed-cc32-42ea-933d-c9eaa80ea201_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
<br>&gt=3B B. Section 2.1.4<br>&gt=3B <br>&gt=3B I'm not really sure what t=
his section is trying to accomplish.  It seems<br>&gt=3B to be a lot about =
deployment guidelines instead of design guidelines.<br>&gt=3B I'm also not =
convinced that the use of complex attributes makes things<br>&gt=3B less se=
cure.  It does not seem this section belongs in this document. <br><br>I th=
ink this section is trying to make a point relating to the security<br>prop=
erties of complex or opaque attributes=2C particularly in the case of<br>at=
tributes sent from the RADIUS client to server.&nbsp=3B <br><br>However=2C =
it occurs to me that the security risks depend quite a bit<br>on how the co=
mplex or opaque attribute is structured.&nbsp=3B An "opaque" attribute that=
 <br>contains complex structures such as ASN.1 or XML would represent<br>a =
considerably larger security risk than say=2C a complex attribute <br>inclu=
ding multiple 32-bit fields. <br><br>It also occurs to me that some of the =
same security risks could be<br>present in simple attributes.&nbsp=3B For e=
xample=2C even though a "string"<br>attribute might be widely implemented=
=2C if an attribute incorporates<br>a new concatenation mechanism=2C then s=
uch an attribute might<br>introduce a buffer-overun vulnerability that woul=
d be unlikely<br>to occur in the case of a complex attribute consisting of =
fixed fields. <br><br><br><br><br> 		 	   		  </body>
</html>=

--_6666a5ed-cc32-42ea-933d-c9eaa80ea201_--

Delivery-date: Mon, 21 Dec 2009 07:44:07 +0000
From: Bernard Aboba <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 20 Dec 2009 23:43:11 -0800

--_a1e3b434-d744-461d-aa49-3c97ae410fda_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> A. Section 2.1.3 =20
>=20
> "code change". =20

a. Enabling a RADIUS server to send a complex attribute=3B
b. Enabling a RADIUS server to receive a complex attribute=3B=20
c. Enabling a RADIUS client to send a complex attribute=3B
d. Enabling a RADIUS client to receive a complex attribute.=20

However=2C rather than examining each of these aspects separately=2C the se=
ction
appears to switch between the aspects=2C sometimes within the same paragrap=
h.=20
As a result=2C it is not always clear what aspects are being discussed.  Si=
nce the
arguments made depend on what aspect is being discussed=2C it can be hard t=
o
follow.=20

For example=2C the second paragraph of Section 2.1.3 seems to focus largely=
 on a).  As you say=2C
in this case=2C a RADIUS server can send a complex attribute without a code=
 change=20
(merely by encoding it as a string). =20

However=2C while the first bullet appears to apply to aspect a) (e.g. ease =
of data entry)=2C=20
the second and third bullets appear to relate either to aspect b) or d). =20

On reading the second and third bullets=2C I'm not sure which aspect is bei=
ng referred to.=20
In paragraph 4=2C it is noted that RADIUS clients require code changes to s=
upport any=20
attribute=2C regardless of whether it is complex or not.   Therefore one ca=
nnot make
an argument about additional code changes arising from aspect c) or d)=2C o=
nly=20
aspect b).=20

Presumably=2C with respect to aspect d)=2C a RADIUS client receiving a comp=
lex attribute=20
would also implement the required parsing and validation routes for that=20
attribute (if not=2C then the client would either ignore the attribute=2C o=
r possibly reject the=20
Access-Response).   So on reading this=2C I'm not sure that the "additional=
 error checking"
applies to=2C exactly.=20

In reading paragraph 3 about server code changes=2C there does not appear t=
o be a
distinction between aspect a (in which code changes are not required) and a=
spect b
(in which a code change would be necessary). =20

Paragraph 4 does make the distinction between aspects c and d.=20

However=2C paragraph 6 mixes aspects a) and b).  Paragraph 4 seems to asser=
t that code
changes are not required for aspect a)=2C while this paragraph does seem to=
 say
that this is possible=2C though it is not clear in what circumstances this =
would be
necessary.=20
 		 	   		  =

--_a1e3b434-d744-461d-aa49-3c97ae410fda_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
&gt=3B A. Section 2.1.3  <br>&gt=3B <br>&gt=3B I did not find the discussio=
n of complex attributes very compelling.<br>&gt=3B Its not clear to me what=
 the difference between string and complex<br>&gt=3B attribute is.  If your=
 RADIUS server supports string then it seems that<br>&gt=3B it would be pos=
sible to support a complex attribute without requiring a<br>&gt=3B "code ch=
ange".  <br><br>There are several distinct aspects that are discussed in Se=
ction 2.1.3:<br><br>a. Enabling a RADIUS server to send a complex attribute=
=3B<br>b. Enabling a RADIUS server to receive a complex attribute=3B <br>c.=
 Enabling a RADIUS client to send a complex attribute=3B<br>d. Enabling a R=
ADIUS client to receive a complex attribute. <br><br>However=2C rather than=
 examining each of these aspects separately=2C the section<br>appears to sw=
itch between the aspects=2C sometimes within the same paragraph. <br>As a r=
esult=2C it is not always clear what aspects are being discussed.&nbsp=3B S=
ince the<br>arguments made depend on what aspect is being discussed=2C it c=
an be hard to<br>follow. <br><br>For example=2C the second paragraph of Sec=
tion 2.1.3 seems to focus largely on a).&nbsp=3B As you say=2C<br>in this c=
ase=2C a RADIUS server can send a complex attribute without a code change <=
br>(merely by encoding it as a string).&nbsp=3B <br><br>However=2C while th=
e first bullet appears to apply to aspect a) (e.g. ease of data entry)=2C <=
br>the second and third bullets appear to relate either to aspect b) or d).=
&nbsp=3B <br><br>On reading the second and third bullets=2C I'm not sure wh=
ich aspect is being referred to. <br>In paragraph 4=2C it is noted that RAD=
IUS clients require code changes to support any <br>attribute=2C regardless=
 of whether it is complex or not.&nbsp=3B&nbsp=3B Therefore one cannot make=
<br>an argument about additional code changes arising from aspect c) or d)=
=2C only <br>aspect b). <br><br>Presumably=2C with respect to aspect d)=2C =
a RADIUS client receiving a complex attribute <br>would also implement the =
required parsing and validation routes for that <br>attribute (if not=2C th=
en the client would either ignore the attribute=2C or possibly reject the <=
br>Access-Response).&nbsp=3B&nbsp=3B So on reading this=2C I'm not sure tha=
t the "additional error checking"<br>applies to=2C exactly. <br><br>In read=
ing paragraph 3 about server code changes=2C there does not appear to be a<=
br>distinction between aspect a (in which code changes are not required) an=
d aspect b<br>(in which a code change would be necessary).&nbsp=3B <br><br>=
Paragraph 4 does make the distinction between aspects c and d. <br><br>Howe=
ver=2C paragraph 6 mixes aspects a) and b).&nbsp=3B Paragraph 4 seems to as=
sert that code<br>changes are not required for aspect a)=2C while this para=
graph does seem to say<br>that this is possible=2C though it is not clear i=
n what circumstances this would be<br>necessary. <br> 		 	   		  </body>
</html>=

--_a1e3b434-d744-461d-aa49-3c97ae410fda_--

Delivery-date: Mon, 21 Dec 2009 05:33:11 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 20 Dec 2009 21:31:44 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

=20

> From: Alan DeKok [mailto:[email-masked]]=20
>=20
> >=20
> > Its not clear to me what the difference between string and complex=20
> > attribute is.  If your RADIUS server supports string then it seems=20
> > that it would be possible to support a complex attribute without=20
>=20
>=20
>   There is no question that a RADIUS server can *transport*=20
> any complex attribute if the attribute is treated as type=20
> "string".  However, having the RADIUS server parse that=20
>=20
requirement.   =20

>   Perhaps a better argument is to ask "why?".  i.e. Why is a=20
> data structure being sent when the contents could have been=20
>=20
basic attributes.   =20

>   The document tries to suggest that where possible, complex=20
> attributes should be replaced by attributes with standard=20
> data types.  Where that is not possible, complex attributes=20
> could be used.
>
> > B. Section 2.1.4
> >=20
> > I'm not really sure what this section is trying to accomplish.  It=20
> > seems to be a lot about deployment guidelines instead of=20
> design guidelines.
> > I'm also not convinced that the use of complex attributes=20
> makes things=20
> > less secure.  It does not seem this section belongs in this=20
> document.
>=20
>=20
[Joe] Complex attributes don't always require code changes and if you
are adding several new basic attributes that need to be validated
together then you need code to do that.=20

>   The intent of this section is to explain some of the=20
> reasons behind the recommendations, rather than to have them=20
> appear out of thin air.
>=20
> > C. Section 5
> >=20
> > This section references section 2.1.4, however it does not=20
> seem there=20
> > is anything actionable for a protocol document to do with=20
> section 2.1.4.
>=20
>=20
[Joe] OK, I think that makes more sense.=20

> > D. Section A.2.2
> >=20
> > Since I did not agree with the motivation for section=20
> 2.1.3, I don't=20
>=20
>   This is one point where I strongly disagree.  It can be=20
>=20
>   Would you counter this section by suggesting it's a *good*=20
> idea to have complex attributes, where standard ones would do=20
>=20
[Joe] That does not seem to be what section A.2.2 states.  It talks
about whether attributes need dynamic computation or not.  It seems the
second and third bullet outlaw all cases, since the first covers dynamic
computation and the second covers static attributes. =20

> > E. Section A.2.1
> >=20
> > I don't see how defining a polymorphic attribute as multiple=20
> > attributes helps.  I'm probably missing something, do you=20
> have an example?
>=20
>=20
> - Attribute X means "integer", unless there is another=20
> attribute Y in the packet, in which case Attribute X means=20
> "mac address"
>=20
>   Both the size and contents of the attribute changes. =20
> There's really no good reason.  Instead, two standard=20
>=20
[Joe] OK, got it.=20

>=20

Delivery-date: Sat, 19 Dec 2009 07:50:33 +0000
Date: Sat, 19 Dec 2009 08:49:05 +0100
From: Alan DeKok <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

  Alan DeKok.

Delivery-date: Sat, 19 Dec 2009 04:19:19 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Fri, 18 Dec 2009 20:17:45 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

comments or not. =20

A. Section 2.1.3 =20

"code change". =20

B. Section 2.1.4

I'm not really sure what this section is trying to accomplish.  It seems
to be a lot about deployment guidelines instead of design guidelines.
I'm also not convinced that the use of complex attributes makes things
less secure.  It does not seem this section belongs in this document.=20

C. Section 5

This section references section 2.1.4, however it does not seem there is
anything actionable for a protocol document to do with section 2.1.4.=20

D. Section A.2.2

Since I did not agree with the motivation for section 2.1.3, I don't
find this section compelling.=20

E. Section A.2.1

I don't see how defining a polymorphic attribute as multiple attributes
helps.  I'm probably missing something, do you have an example?=20

> From: [email-masked]=20
>=20
> This is announcing a "Last Look" at the RADIUS Design=20
> Guidelines document.  This "Last Look" will last until=20
>=20
> Friday, December 18, 2009. =20
>=20
> =20
>=20
> Since the Design Guidelines document has already completed=20
>=20
> and IESG review (no outstanding DISCUSS comments), the=20
>=20
> all Issues brought up in IETF last call and the IESG Issues=20
> list (as noted in Draft Tracker) have been resolved.=20
>=20
> =20
>=20
>=20
>=20
> =20
>=20
> Please send comments relating to the document to the RADEXT=20
> WG mailing list ([email-masked]).=20
>=20
> As usual, if you are submitting Issues, please utilize the=20
>=20
>=20
> =20
>=20
>=20

Delivery-date: Fri, 04 Dec 2009 15:22:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: "Last Look" at the RADIUS Design Guidelines document
Date: Fri, 4 Dec 2009 07:22:30 -0800

------=_NextPart_000_0038_01CA74B2.8AD695C0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

------=_NextPart_000_0038_01CA74B2.8AD695C0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"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;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@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=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>This is announcing a &#8220;Last Look&#8221; at the =
RADIUS
Design Guidelines document.&nbsp; This &#8220;Last Look&#8221; will last =
until <o:p></o:p></p>

<p class=3DMsoNormal>Friday, December 18, 2009.&nbsp; <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Since the Design Guidelines document has already =
completed
RADEXT WG last call (twice), IETF last call,<o:p></o:p></p>

<p class=3DMsoNormal>and IESG review (no outstanding DISCUSS comments), =
the
purpose of this &#8220;Last Look&#8221; is to confirm =
that<o:p></o:p></p>

<p class=3DMsoNormal>all Issues brought up in IETF last call and the =
IESG Issues
list (as noted in Draft Tracker) have been resolved. <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The document is available here:<o:p></o:p></p>

<p class=3DMsoNormal><b><a
href=3D"http://www.ietf.org/id/draft-ietf-radext-design-10.txt">http://ww=
w.ietf.org/id/draft-ietf-radext-design-10.txt</a><o:p></o:p></b></p>

<p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p>

<p class=3DMsoNormal>Please send comments relating to the document to =
the RADEXT
WG mailing list (<a =
href=3D"mailto:[email-masked]">[email-masked]</a>). =
<o:p></o:p></p>

<p class=3DMsoNormal>As usual, if you are submitting Issues, please =
utilize the
Issue format described in the RADIUS WG<o:p></o:p></p>

<p class=3DMsoNormal>Issue list (<a =
href=3D"http://www.drizzle.com/~aboba/RADEXT">http://www.drizzle.com/~abo=
ba/RADEXT</a>
)<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0038_01CA74B2.8AD695C0--

Delivery-date: Fri, 04 Dec 2009 10:15:07 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-10.txt 
Date: Fri,  4 Dec 2009 02:15:02 -0800 (PST)

--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-10.txt
	Pages           : 38
	Date            : 2009-12-04

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-10.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-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 04 Dec 2009 10:06:55 +0000
Date: Fri, 04 Dec 2009 11:05:49 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Revised Resolution to Issue 319

Bernard Aboba wrote:
> In Section 1.3:
> 
>    The uses of "MUST" and "MUST NOT" in this document are limited to (a)
>    requirements to follow the IETF process for IETF standards, and (b)
>    quotes from other documents.  As a result, the use of MUST and MUST
>    NOT in this document does not prescribe new mandatory behavior within
>    implementations.
> 
> Wasn't this to have gone in Section 1.2?

  OK.

> Section 2.1.1 states:
...
> Yet Section A.1.1 says:
> 
>       * Interface-Id (8 octets in network byte order)
> 
> 
> Should this say: 
>  
>     * Interface-Id (8 octet string in network byte order)

  Yes.  I'll post an updated draft shortly.

  Alan DeKok.