Subject: Re: Review of draft-ietf-radext-vlan-02.txt
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 31 Mar 2006 19:24:38 +0200

Hi Bernard,

thanks for the quick response. Please find some comments below:

Bernard Aboba wrote:
>> The document does not describe the semantic when the 
>> User-Priority-Table attribute is included in the Access-Request.
> 
> 
> I was also a bit puzzled by this.  Presumably the switch sends the 
> default configuration, but I am not sure.
> 
>> Section 1.3 talks about the provisioning semantic when included in the 
>> Access-Accept. I think it is necessary to describe the semantical 
>> difference between these two approaches.
> 
> 
> The document says that the attribute when included in the Access-Request 
> is a "hint".  So I don't think that there is any provisioning going on 
> in the Access-Request.

Do you think it would be useful to provide more description of what the
semantic of the User-Priority-Table attribute in the Access-Request or
the Access-Accept means?

I know you as someone that wants to describe the behavior in great detail.

> 
>> How is the data traffic mapped to the QoS class? Which attribute 
>> carries this flow identifier? I think it is necessary to provide a 
>> description.
> 
> 
> My understanding is that we are only talking about remapping of priority 
> bits that are already set on inbound, and that this is described in IEEE 
> 802.1D.

What type of remapping of priority bits do you have in mind?

Note that the reference to Annex G in the draft is a bit misleading 
since this section of the IEEE 802.1D spec just gives the rational 
behind the selection of the traffic classes based on the number of 
queues being available.

> 
>> Why is the length of the value carried in the User-Priority-Table 
>> attribute 10 bytes long?
> 
> 
> It isn't.  RADIUS includes the type and length fields in the total 
> length, so it's 8 bytes long.

Why is it 8 bytes long?

> 
>> You seem to assume that the RADIUS server knows something about the 
>> link specific properties.
> 
> 
> The document specifies attributes for use with IEEE 802 networks.  
> Information on the specific link type is provided in the NAS-Port-Type 
> attribute.
That's something you might want to mention in the document.

I think you just want to delete the usage of the User-Priority-Table
attribute in the Access-Request.

> 
>> 1) What happens if the RADIUS server receives the User-Priority-Table 
>> attribute in the Access-Request but it has only Y.1541 QoS classes 
>> stored in the user's profile?
> 
> 
> Since this would be a hint, I presume the server is free to ignore it.
> 
>> Do you assume that the RADIUS server is able to provide a mapping?
> 
> 
> Since it's a hint, I wouldn't think so.  The RADIUS server isn't 
> compelled to include the User-Priority-Table attribute in the 
> Access-Accept.
> 
>> Should the RADIUS server fail when it either does not understand the 
>> QoS classes or if it is unable to map them?
> 
> 
> It is possible that implementations may not react well to the hint, but 
> if they do understand the hint, they shouldn't fail because they don't 
> return a User-Priority-Table in the Access-Accept.
> 
>> Should the RADIUS client know what the RADIUS server understands?
> 
> 
> I think that is only important if RADIUS servers won't react well to the 
> hint.  If servers don't send the attribute, the client probably won't care.
> 
>> 2) Is the an applicability problem with provisioning in a roaming 
>> environment when the RADIUS server of my home network sends the 
>> User-Priority-Table attribute to the visited network which might be a 
>> IEEE 802.16e network?
> 
> 
> Presumably the attribute will only be sent if the NAS-Port-Type 
> attribute indicates that it would be useful.  802.16k implements 
> bridging, but 802.16e does not, so I don't think it would make sense to 
> send this attribute to a RADIUS client running 802.16e.  However, it 
> appears there is no NAS-Port-Type for 802.16e, 802.16k, 802.20, etc.  
> There probably should be.
> 
>> Would it be necessary for the RADIUS client to indicate that it is 
>> attached to a IEEE 802.1D network with support for the QoS classes in 
>> order to allow the Access-Accept message to be meaningful?
> 
> 
> The NAS-Port-Type attribute should provide this information.
> 
>> How long is the authoriziation decision valid when the 
>> User-Priority-Table attribute in sent in the Access-Request?
> 
> 
> Presumably until the expiration of Session-Timeout.
> 
>> Do you see a need to reflect the QoS decision in the interworking with 
>> accounting or RADIUS prepaid (e.g., cost of the reservation)?
> 
> 
> The attributes are not indicated to be sent in Accounting-Request 
> packets, but perhaps they should be.

It seems that you need to add a little bit more text to the draft to 
explain based on your response.

Let me explain what I would do with the description of this specific 
attribute:

The User-Priority-Table attribute is only used in the Access-Accept (and 
not in the Access-Request). You need to specify which traffic is 
assigned to a specific QoS class. Therefore, you need to add the 
NAS-Traffic-Rule. You need to add a normative reference to 
draft-ietf-radext-filter-rules-00.txt.

Furthermore, you need to add the User-Priority-Table attribute to 
Accounting-Request messages.

Without a description which traffic experiences the QoS treatment the 
entire stuff does not make sense.

 From a semantic point of view this is very similar to a DiffServ 
traffic marking. Here the rules for traffic marking is stored at the AAA 
server.
This raises the question why you cannot just have a generic description 
with a set of QoS parameters. For IEEE 802.16e you would have to go 
through the same description just with different QoS parameters. The 
same for DiffServ, IntServ CL/GS, Y.1541, etc.

Ciao
Hannes

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

Delivery-date: Fri, 31 Mar 2006 18:08:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Review of draft-ietf-radext-vlan-02.txt
Date: Fri, 31 Mar 2006 10:08:05 -0800

>Do you think it would be useful to provide more description of what the 
>semantic of the User-Priority-Table attribute in the Access-Request or the 
>Access-Accept means?

Since there is some confusion on that point, I think the answer is probably 
"yes".   I also think there may be more text required to specify exactly 
what 802.1D management elements this corresponds to.

>Note that the reference to Annex G in the draft is a bit misleading since 
>this section of the IEEE 802.1D spec just gives the rational behind the 
>selection of the traffic classes based on the number of queues being 
>available.

I think that the correct reference may be Section 7.5.1 ("Regerating User 
Priority").  Annex G just provides some general background information.   
Table 7.1 specifies the default values of the User Priority Regeneration 
Table (no change).  Clause 14.6.2 talks about modification of the default 
values by management.  My assumption is that the User-Priority-Table 
attribute sent in an Access-Request would be the default in Table 7.1, 
absent changes via management.

>Why is it 8 bytes long?

Clause 14.6.2.3.3 specifies the regeneration table as 8 values, each an 
integer in the range of 0-7.

>That's something you might want to mention in the document.

Indeed.

>I think you just want to delete the usage of the User-Priority-Table
>attribute in the Access-Request.

Personally, I'm not clear what a RADIUS server would do with it;  unless 
it's been modified by management it is a known quantity (e.g. the default).

>It seems that you need to add a little bit more text to the draft to 
>explain based on your response.

I think so.  This would include:

a. References to specific sections of 802.1D, explaining how this attribute 
relates to existing management objects.
b. Discussion of the semantics of inclusion in Access-Request (if this is in 
fact required)

>The User-Priority-Table attribute is only used in the Access-Accept (and 
>not in the Access-Request). You need to specify which traffic is assigned 
>to a specific QoS class. Therefore, you need to add the NAS-Traffic-Rule. 
>You need to add a normative reference to 
>draft-ietf-radext-filter-rules-00.txt.

As far as I can tell, the regeneration table doesn't assign traffic to a 
specific QoS class, it just remaps it.  This isn't based on filters, but 
just on the incoming markings.  Obviously this is not a very sophisticated 
usage model.

>Furthermore, you need to add the User-Priority-Table attribute to 
>Accounting-Request messages.

Probably.

>Without a description which traffic experiences the QoS treatment the 
>entire stuff does not make sense.

I think that regeneration is a separate issue from QoS treatment.  I agree 
that it would not make much sense to do regeneration if you didn't have a 
QoS goal in mind, though.

>From a semantic point of view this is very similar to a DiffServ traffic 
>marking. Here the rules for traffic marking is stored at the AAA server.

Regeneration is a kind of remapping (though not a sophisticated one).

>This raises the question why you cannot just have a generic description 
>with a set of QoS parameters.

Clearly that would be useful, but I think it is outside the scope of what 
the regeneration table is attempting to achieve.

--
to unsubscribe send a message 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, 31 Mar 2006 15:24:30 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Fri, 31 Mar 2006 09:22:42 -0600
From: "Carl Kalbfleisch" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Nelson, David
> Sent: Tuesday, March 28, 2006 12:19 PM
> To: [email-masked]
> Subject: RE: looking for advise on RFC-2618 and 2620
>=20
>=20
> Carl Kalbfleisch writes...
>=20
> > I realize that these MIBs are being updated,
> > so perhaps we can add a discontinuity timer in a future revision.=20
>=20
> This is already an open issue from Area Director review of the revised
> MIB drafts, so will be included in the next draft version.
>=20

Several more comments on discontinuity:

1) =
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-=
05.txt defines only one object.

   radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
          SYNTAX TimeTicks
          UNITS  "hundredths of a second"
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
                "The time (in hundredths of a second) since the
                 DAC module was last re-initialized."
          ::=3D { radiusDynAuthClientScalars 3 }

I recommend adding this attribute to the RadiusDynAuthServerEntry =
instead. The issue is that (for example in our box) we have instances of =
authentication MIB tables spread accross multiple nodes. Therefore it is =
possible for a node to reboot and have discontinuities independent of =
the mib as a whole.

2) The update to RFC-2618 =
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt =
does not have a discontinuity timer. Again, I suggest adding the value =
to the table. Also, it there some reason why the authors did not just =
deprecate the radiusAuthServerAddress and then add the IPv6 attributes =
to the existing table. IE, why deprecate the entire table.

3) same comments as 2 for the uptdate to RFC 2620 - =
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-02.txt

I have not implemented the server side mibs or reviewed the updates to =
them. The same or similar comments might apply.

> > if so, I would suggest adding it per radius entry so that
> > each server can have its own value.
>=20
> That seems like a reasonable suggestion.
>=20

Any idea when the next revision of the updates for 2618 and 2620 would =
be published?

> > One other point to note. We have found that radius servers respond
> faster
> > than 100th of a second. I'd suggest an update to the MIB where the
> > response time is stored in micro-seconds. In addition, having the
> minimum,
> > maximum and average are also helpful. We are adding such=20
> values to our
> > enterprise MIB, but would opt for standard attributes if=20
> they existed.
>=20
> The revised MIBs have already been through WG last call and are now in
> IESG review.  Does the WG wish to recall the documents from the
> publication requested state to consider adding this kind of=20
> new feature?
>=20
>=20

Any one interested in this?

Carl

--
to unsubscribe send a message 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, 29 Mar 2006 23:50:49 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-05.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500

--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		: Dynamic Authorization Client MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-client-mib-05.txt
	Pages		: 30
	Date		: 2006-3-29
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-dynauth-client-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynauth-client-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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: Wed, 29 Mar 2006 23:50:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-05.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500

--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		: Dynamic Authorization Server MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-server-mib-05.txt
	Pages		: 28
	Date		: 2006-3-29
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-dynauth-server-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynauth-server-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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: Wed, 29 Mar 2006 17:59:06 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Wed, 29 Mar 2006 09:58:17 -0800

>The document does not describe the semantic when the User-Priority-Table 
>attribute is included in the Access-Request.

I was also a bit puzzled by this.  Presumably the switch sends the default 
configuration, but I am not sure.

>Section 1.3 talks about the provisioning semantic when included in the 
>Access-Accept. I think it is necessary to describe the semantical 
>difference between these two approaches.

The document says that the attribute when included in the Access-Request is 
a "hint".  So I don't think that there is any provisioning going on in the 
Access-Request.

>How is the data traffic mapped to the QoS class? Which attribute carries 
>this flow identifier? I think it is necessary to provide a description.

My understanding is that we are only talking about remapping of priority 
bits that are already set on inbound, and that this is described in IEEE 
802.1D.

>Why is the length of the value carried in the User-Priority-Table attribute 
>10 bytes long?

It isn't.  RADIUS includes the type and length fields in the total length, 
so it's 8 bytes long.

>You seem to assume that the RADIUS server knows something about the link 
>specific properties.

The document specifies attributes for use with IEEE 802 networks.  
Information on the specific link type is provided in the NAS-Port-Type 
attribute.

>1) What happens if the RADIUS server receives the User-Priority-Table 
>attribute in the Access-Request but it has only Y.1541 QoS classes stored 
>in the user's profile?

Since this would be a hint, I presume the server is free to ignore it.

>Do you assume that the RADIUS server is able to provide a mapping?

Since it's a hint, I wouldn't think so.  The RADIUS server isn't compelled 
to include the User-Priority-Table attribute in the Access-Accept.

>Should the RADIUS server fail when it either does not understand the QoS 
>classes or if it is unable to map them?

It is possible that implementations may not react well to the hint, but if 
they do understand the hint, they shouldn't fail because they don't return a 
User-Priority-Table in the Access-Accept.

>Should the RADIUS client know what the RADIUS server understands?

I think that is only important if RADIUS servers won't react well to the 
hint.  If servers don't send the attribute, the client probably won't care.

>2) Is the an applicability problem with provisioning in a roaming 
>environment when the RADIUS server of my home network sends the 
>User-Priority-Table attribute to the visited network which might be a IEEE 
>802.16e network?

Presumably the attribute will only be sent if the NAS-Port-Type attribute 
indicates that it would be useful.  802.16k implements bridging, but 802.16e 
does not, so I don't think it would make sense to send this attribute to a 
RADIUS client running 802.16e.  However, it appears there is no 
NAS-Port-Type for 802.16e, 802.16k, 802.20, etc.  There probably should be.

>Would it be necessary for the RADIUS client to indicate that it is attached 
>to a IEEE 802.1D network with support for the QoS classes in order to allow 
>the Access-Accept message to be meaningful?

The NAS-Port-Type attribute should provide this information.

>How long is the authoriziation decision valid when the User-Priority-Table 
>attribute in sent in the Access-Request?

Presumably until the expiration of Session-Timeout.

>Do you see a need to reflect the QoS decision in the interworking with 
>accounting or RADIUS prepaid (e.g., cost of the reservation)?

The attributes are not indicated to be sent in Accounting-Request packets, 
but perhaps they should be.

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

Delivery-date: Tue, 28 Mar 2006 18:19:28 +0000
Content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Tue, 28 Mar 2006 13:19:13 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Carl Kalbfleisch writes...

> I realize that these MIBs are being updated,
> so perhaps we can add a discontinuity timer in a future revision.=20

This is already an open issue from Area Director review of the revised
MIB drafts, so will be included in the next draft version.

> if so, I would suggest adding it per radius entry so that
> each server can have its own value.

That seems like a reasonable suggestion.

> One other point to note. We have found that radius servers respond
faster
> than 100th of a second. I'd suggest an update to the MIB where the
> response time is stored in micro-seconds. In addition, having the
minimum,
> maximum and average are also helpful. We are adding such values to our
> enterprise MIB, but would opt for standard attributes if they existed.

The revised MIBs have already been through WG last call and are now in
IESG review.  Does the WG wish to recall the documents from the
publication requested state to consider adding this kind of new feature?

--
to unsubscribe send a message 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, 28 Mar 2006 18:00:09 +0000
content-class: urn:content-classes:message
Subject: looking for advise on RFC-2618 and 2620
Date: Tue, 28 Mar 2006 11:58:20 -0600
From: "Carl Kalbfleisch" <[email-masked]>
To: <[email-masked]>

Hi,

I am a new subscriber to this group. I have implemented RFC-2618 and =
RFC-2620 in our security gateway. We allow the user to configure two =
accounting and two authentication servers. These show up as instances 1 =
and 2 in the associated tables in these MIBs. Now an issue arises if the =
user changes the IP or port of the radius servers. The system is now =
pointing to a different server. However, the counters are still whatever =
they are. I have a request to clear the counters, but this could cause =
spikes in the NMS to think the counter wrapped. What is needed is some =
discontinuity time value. I was thinking of overloading the IP and port =
attributes for our implementation and telling end users that if those =
values change then the counters should be treated as a discontinuity =
event. I realize that this would be non-standard so wanted to get some =
feedback on best practices. I realize that these MIBs are being updated, =
so perhaps we can add a discontinuity timer in a future revision. if so, =
I would suggest adding it per radius entry so that each server can have =
its own value.

One other point to note. We have found that radius servers respond =
faster than 100th of a second. I'd suggest an update to the MIB where =
the response time is stored in micro-seconds. In addition, having the =
minimum, maximum and average are also helpful. We are adding such values =
to our enterprise MIB, but would opt for standard attributes if they =
existed.

Thoughts and comments appreciated.

Carl

--
to unsubscribe send a message 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, 28 Mar 2006 11:40:07 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: digest-auth surgery in Dallas
Date: Tue, 28 Mar 2006 13:39:45 +0200

Hi,

during the RADEXT meeting in Dallas, we came to the conclusion that removing
the client nonce generation mode would solve most - if not all - of
the remaining issues with draft-ietf-radext-digest-auth.

Miguel would have to remove the relating parts from his Diameter draft
as well (sorry).

Anybody objecting to this proposal should speak up >>now<< and suggest how
to address the issues as outlined in
http://www3.ietf.org/proceedings/06mar/slides/radext-0.pdf

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message 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, 28 Mar 2006 11:38:15 +0000
Date: Tue, 28 Mar 2006 05:37:42 -0600
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked]
Subject: Review of draft-ietf-radext-vlan-02.txt

Hi all,

I reviewed the draft and I came across a number of questions. I am 
referring only to the User-Priority-Table attribute.

The document defines a QoS provisioning and authorization solution based 
on traffic classes. These classes are defined in IEEE 802.1D.

The document does not describe the semantic when the User-Priority-Table 
attribute is included in the Access-Request. Section 1.3 talks about the 
provisioning semantic when included in the Access-Accept. I think it is 
necessary to describe the semantical difference between these two 
approaches.

How is the data traffic mapped to the QoS class? Which attribute carries 
this flow identifier? I think it is necessary to provide a description.

Why is the length of the value carried in the User-Priority-Table 
attribute 10 bytes long? (We are talking about 8 QoS classes, as I read 
from Annex G.) Why is the data type a string?

You seem to assume that the RADIUS server knows something about the link 
specific properties. I got the feedback that this is not appreciated for 
QoS. Here are two examples:

1) What happens if the RADIUS server receives the User-Priority-Table 
attribute in the Access-Request but it has only Y.1541 QoS classes 
stored in the user's profile? Do you assume that the RADIUS server is 
able to provide a mapping? Should the RADIUS server fail when it either 
does not understand the QoS classes or if it is unable to map them? 
Should the RADIUS client know what the RADIUS server understands?

2) Is the an applicability problem with provisioning in a roaming 
environment when the RADIUS server of my home network sends the 
User-Priority-Table attribute to the visited network which might be a 
IEEE 802.16e network? According to your description the RADIUS client 
would fail according to the description in Section 1.3.
Would it be necessary for the RADIUS client to indicate that it is 
attached to a IEEE 802.1D network with support for the QoS classes in 
order to allow the Access-Accept message to be meaningful?

How long is the authoriziation decision valid when the 
User-Priority-Table attribute in sent in the Access-Request?

Do you see a need to reflect the QoS decision in the interworking with 
accounting or RADIUS prepaid (e.g., cost of the reservation)?

Ciao
Hannes

PS: It might be good to find a few QoS experts for review of this 
document. I could try to find someone, if you want.

--
to unsubscribe send a message 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, 27 Mar 2006 20:50:22 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-vlan-02.txt 
Date: Mon, 27 Mar 2006 15:50:01 -0500

--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 Attributes for Virtual LAN and Priority Support
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-vlan-02.txt
	Pages		: 14
	Date		: 2006-3-27
	
This document proposes additional RADIUS (Remote Authentication Dial
   In User Service) attributes for dynamic Virtual LAN assignment and
   prioritization, for use by IEEE 802.1X authenticators.  These
   attributes are usable within either RADIUS or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-vlan-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-vlan-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-vlan-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-vlan-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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, 26 Mar 2006 22:42:11 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Editorial nits on prefix delegation
Date: Sun, 26 Mar 2006 17:41:42 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Editorial cmts on prefix delegation
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: March 26th, 2006
Reference: n/a
Document: draft-ietf-radext-delegated-prefix-00.txt
Comment type: 'E'ditorial
Priority: '2' May fix
Section: 2 & 5
Rationale/Explanation of issue:

The draft looks ok to me.  A couple editorial nits:

Section 5:
  "IP SEC" -> "IPsec"

Section 2:
  The idnit checker at tools.ietf.org complains:
    Miscellaneous warnings:
    - The document seems to use RFC 2119 keywords,=20
      but does not seem to contain the recommended=20
      RFC 2119 boilerplate
   because the text of section 2 is not exactly like
   like the boilerplate in 2119 (missing quote marks).
 =20
Greg

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, March 03, 2006 3:02 PM
> To: [email-masked]
> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20
> Attribute"
>=20
> This is an announcement of RADEXT WG last call on the "RADIUS=20
> Delegated-IPv6=20
> Prefix Attribute"
> document, prior to sending this document on to the IESG for=20
> consideration as=20
> a Proposed
> Standard.
>=20
> The document is available for inspection here:
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-0
0.txt
>=20
> RADEXT WG last call will last until Monday March 27, 2006. =20
> Please send your
> comments to the RADEXT WG list ([email-masked]) in the format=20
> described
> on the RADEXT Issues List:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> Since all RADEXT WG last calls require at least 5 reviewers=20
> in order to=20
> advance
> the document, please respond indicating that you have read=20
> the document and
> find it acceptable, even if you have no issues to file.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Sat, 25 Mar 2006 01:18:49 +0000
Content-class: urn:content-classes:message
Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes
Date: Sat, 25 Mar 2006 03:17:48 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Jouni,

>> >  o how to provide Diameter's request redirecting on RADIUS side
>> >    (redirect-host etc + the functionality)
>>=20
>> I was unaware of this request.  I think that satisfying it
>
>Hmm.. I think 3GPP has not asked RADEXT to do anything on=20
>request redirecting, mostly because of the reasons you pointed out
below.
>It is just an open issue for 3GPP under the same topic and as=20
>far as I know it will also stay as their headache.
>
>However, I wouldn't mind having some documented guidelines or=20
>facts on this as I think 3GPP might not be the only SDO /=20
>entity having the same issue.
>
>> will be difficult
>> since RADIUS (unlike Diameter) requires pre-set credentials and does
not
>> support DNS-based location of servers.   Therefore redirection
support alone
>> will not make this work; it is necessary to enhance the RADIUS=20
>> protocol substantially.

So, what is it that you want, in ways of guidelines - why it won't work?

John

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

Delivery-date: Fri, 24 Mar 2006 16:11:26 +0000
Content-class: urn:content-classes:message
Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes
Date: Fri, 24 Mar 2006 17:11:01 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernand,

> >  o how to provide Diameter's request redirecting on RADIUS side
> >    (redirect-host etc + the functionality)
>=20
> I was unaware of this request.  I think that satisfying it=20

Hmm.. I think 3GPP has not asked RADEXT to do anything on request
redirecting, mostly because of the reasons you pointed out below.
It is just an open issue for 3GPP under the same topic and as far
as I know it will also stay as their headache.

However, I wouldn't mind having some documented guidelines or facts
on this as I think 3GPP might not be the only SDO / entity having
the same issue.

> will be difficult=20
> since RADIUS (unlike Diameter) requires pre-set credentials=20
> and does not=20
> support DNS-based location of servers.   Therefore=20
> redirection support alone=20
> will not make this work; it is necessary to enhance the=20
> RADIUS protocol=20
> substantially.

Cheers,
	Jouni

--
to unsubscribe send a message 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, 24 Mar 2006 14:20:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes
Date: Fri, 24 Mar 2006 06:19:57 -0800

>  o how to provide Diameter's NAS-Filter-Rule also on RADIUS
>    (current reference is to now splitted radext-ieee802 draft)

As we discussed in the RADEXT WG meeting, it seems to make sense to define a 
NAS-Filter-Rule attribute in RADIUS, in addition to the Filter-ID and 
NAS-Traffic-Rule attributes.  However, only one of these attributes can be 
included in a single packet.

>  o how to provide Diameter's request redirecting on RADIUS side
>    (redirect-host etc + the functionality)

I was unaware of this request.  I think that satisfying it will be difficult 
since RADIUS (unlike Diameter) requires pre-set credentials and does not 
support DNS-based location of servers.   Therefore redirection support alone 
will not make this work; it is necessary to enhance the RADIUS protocol 
substantially.

--
to unsubscribe send a message 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, 24 Mar 2006 14:00:47 +0000
Content-class: urn:content-classes:message
Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes 
Date: Fri, 24 Mar 2006 15:00:09 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi,

The 3GPP I-WLAN spec 29.234 is the only place in 3GPP scope
that I remember that has D->R and R->D cases (on Wa and Wd
interfaces). Currently the spec only says that the D->R and
R->D cases are done according to the NASREQ and the Diam-EAP.

In 3GPP I-WLAN point of view there are couple open issues
under this topic:
 o how to provide Diameter's NAS-Filter-Rule also on RADIUS
   (current reference is to now splitted radext-ieee802 draft)
 o how to provide Diameter's request redirecting on RADIUS side
   (redirect-host etc + the functionality)

Cheers,
	Jouni

=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: 24. maaliskuuta 2006 3:09
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Dime] RE: RADIUS to Diameter gateways & extended attributes=20
>=20
> Hi all,
>=20
> >David Mitton <[email-masked]> wrote:
> >> I'd like to hear from people that actually have such things, as we=20
> >> didn't get very many responses in the Dime meeting room. =20
> I'll chase=20
> >> that in a different thread.
> >
> >  Knowing current D->R gateway practices would help, thanks.
>=20
> Could some people on the DiME mailing list point out anything?  I know
> that 3GPP has some plans for such things.  Maybe someone could explain
> what is happening in 3GPP or other SD0s?
>=20
> John
>=20
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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

Delivery-date: Fri, 24 Mar 2006 05:07:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Last look at VLAN and Priority Document
Date: Thu, 23 Mar 2006 21:07:23 -0800

RADEXT WG last call has completed on the RADIUS VLAN and Priority document, 
and all issues appear to have been resolved.  The updated document is 
available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-01.txt

Please have a look at the document.  If we do not hear about any additional 
issues we will send the document on to the iESG for consideration as a 
Proposed Standard by March 30, 2006.

--
to unsubscribe send a message 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, 24 Mar 2006 04:51:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Radius Dyn auth MIBs with the updates
Date: Fri, 24 Mar 2006 10:20:29 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64EFE.91449025
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
=20
We realized that the compliance statement doesn't say that this MIB
support IPv4 addresses ONLY. May be this statement is OK for the other
four MIBs since they had old IPv4-only MIBs.  But even there since they
obsolete(correct?) the old MIBs, should they also spell similar to the
inline comment.
=20
 4. Compliance statements now say that we only support IPv4 and IPV6 =20
=20
 Here is the compliance statement and the new objects.

	radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE
	       STATUS  current
	       DESCRIPTION
	             "The compliance statement for entities implementing
	              the RADIUS Dynamic Authorization Client.
Implementation
	        of this module is for entities that support IPv6, or
	        support IPv4 and IPv6."
	       MODULE  -- this module
	       MANDATORY-GROUPS { radiusDynAuthClientMIBGroup }

	      =20

	 <Nagi> Should it be something like "Implementation of this
module is for entities that support IPv4 or IPv6 or both IPv4 and IPv6".
Does this make sense?

	=20

	Thanks

	Nagi.

	=20

	   =20

	=20
	=20
	=20
	=20

------_=_NextPart_001_01C64EFE.91449025
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3D640284004-24032006><FONT=20
color=3D#0000ff>All,</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
face=3DArial><FONT=20
size=3D2><SPAN =
class=3D640284004-24032006></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3D640284004-24032006><FONT color=3D#0000ff>We =
realized=20
that&nbsp;the compliance statement&nbsp;doesn't say that this MIB =
support=20
IPv4&nbsp;addresses&nbsp;ONLY.&nbsp;May be this statement is&nbsp;OK for =
the=20
other four MIBs since they had old IPv4-only MIBs. </FONT>&nbsp;<FONT=20
color=3D#0000ff>But even there since&nbsp;they obsolete(correct?) the =
old MIBs,=20
should they also spell similar to the inline=20
comment.</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
face=3DArial><FONT=20
size=3D2><SPAN =
class=3D640284004-24032006></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3D640284004-24032006>&nbsp;</SPAN>4. Compliance =
statement<SPAN=20
class=3D982173806-23032006>s</SPAN> now say that we only support IPv4 =
and=20
IPV6&nbsp;<SPAN class=3D640284004-24032006><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
size=3D+0><FONT=20
face=3DArial><FONT size=3D2><SPAN=20
class=3D640284004-24032006></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D982173806-23032006><FONT =
size=3D+0><FONT=20
face=3DArial><FONT size=3D2><SPAN =
class=3D640284004-24032006>&nbsp;</SPAN><SPAN=20
class=3D982173806-23032006>Here is the compliance statement and the new=20
objects.</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>
  <P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2>radiusDynAuthClientMIBCompliance=20
  MODULE-COMPLIANCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STATUS&nbsp; =

  current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  "The compliance statement for entities=20
  =
implementing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  the RADIUS Dynamic Authorization Client.=20
  Implementation<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of this =
module is=20
  for entities that support IPv6,=20
  or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support IPv4 and=20
  IPv6."<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MODULE&nbsp; -- this=20
  module<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MANDATORY-GROUPS {=20
  radiusDynAuthClientMIBGroup }</FONT></SPAN></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D982173806-23032006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  class=3D640284004-24032006><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D982173806-23032006><SPAN=20
  class=3D640284004-24032006>&nbsp;</SPAN></SPAN><SPAN=20
  class=3D982173806-23032006><SPAN =
class=3D640284004-24032006>&lt;Nagi&gt; Should it=20
  be something like "Implementation&nbsp;of this module is for entities =
that=20
  support IPv4 or IPv6 or&nbsp;both IPv4 and IPv6". Does this make=20
  sense?</SPAN></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D982173806-23032006><SPAN=20
  class=3D640284004-24032006></SPAN></SPAN></FONT></FONT>&nbsp;</P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D982173806-23032006><SPAN=20
  class=3D640284004-24032006>Thanks</SPAN></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D982173806-23032006><SPAN=20
  class=3D640284004-24032006>Nagi.</SPAN></SPAN></FONT></FONT></P>
  <P><SPAN class=3D982173806-23032006><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D640284004-24032006>&nbsp;</SPAN></FONT></FONT></SPAN></P>
  <P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN=20
  class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2></FONT></SPAN></P></FONT></SPAN></DIV>
  <DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C64EFE.91449025--

--
to unsubscribe send a message 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, 24 Mar 2006 01:09:03 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS to Diameter gateways & extended attributes 
Date: Fri, 24 Mar 2006 03:08:49 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi all,

>David Mitton <[email-masked]> wrote:
>> I'd like to hear from people that actually have such things, as we=20
>> didn't get very many responses in the Dime meeting room.  I'll chase=20
>> that in a different thread.
>
>  Knowing current D->R gateway practices would help, thanks.

Could some people on the DiME mailing list point out anything?  I know
that 3GPP has some plans for such things.  Maybe someone could explain
what is happening in 3GPP or other SD0s?

John

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

Envelope-to: [email-masked]
Delivery-date: Fri, 24 Mar 2006 01:05:22 +0000
From: "Alan DeKok" <[email-masked]>
To: David Mitton <[email-masked]>
Subject: Re: RADIUS to Diameter gateways & extended attributes 
cc: [email-masked]
Date: Thu, 23 Mar 2006 20:13:09 -0500
Message-Id: <[email-masked]>

David Mitton <[email-masked]> wrote:
> I'd like to hear from people that actually have such things, as we 
> didn't get very many responses in the Dime meeting room.  I'll chase 
> that in a different thread.

  Knowing current D->R gateway practices would help, thanks.

> We already have this.  It's the Origin-AAA-Protocol AVP (AVP Code 408)
> RFC 4005, Section 9.3.6

  Which talks about the message origin, not attribute origin.

  Since Diameter servers can use RADIUS attributes in Diameter
messages, D->R gateways may receive many "RADIUS" attributes in a
Diameter message, and may not be able to encapsulate them all in
RADIUS.

  This would appear to be a larger problem than just the Diameter
attribute format in RADIUS that we've been discussing until now.  I
haven't been following Diameter, so I have no idea if this *is* a
problem in practice, and if so, how do implementations deal with it.

  Alan DeKok.

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

Delivery-date: Fri, 24 Mar 2006 00:16:16 +0000
Date: Thu, 23 Mar 2006 19:16:01 -0500
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: Re: RADIUS to Diameter gateways & extended attributes

At 3/21/2006 02:08 PM, you wrote:
>   Some issues were raised during the WG meeting today.  I'll try to
>address them here.
>
>   The purpose behind using the Diameter format to carry extended
>RADIUS attributes is to simplify the work done by RADIUS to Diameter
>gateways.  As a result, any issue of Diameter to RADIUS gatewaying and
>attribute/message size is largely out of scope.
>
>   That is, it doesn't matter so much that Diameter can carry much more
>traffic per attribute/message than RADIUS can, because that is not the
>purpose behind the use of the Diameter attribute format.  If that is
>true, we then have to ensure that Diameter to RADIUS gateways don't
>pass large Diameter attributes/messages to RADIUS.
>
>   Since we already have Diameter to RADIUS gateways that perform this
>enforcement, it would appear that this worry is largely not a problem
>in practice.

I'd like to hear from people that actually have such things, as we 
didn't get very many responses in the Dime meeting room.  I'll chase 
that in a different thread.

>   However... with the advent of many more RADIUS attributes being
>carried in Diameter, it would be good to enable Diameter to RADIUS
>gateways to tell which attributes *can* fit into RADIUS, and which
>cannot.  One suggestion in the "extended attribute" subgroup was to
>allocate the Diameter-format RADIUS attributes from a subset of the
>Diameter space.  The gateways could then trivially tell which
>attributes are RADIUS compatible.
>
>   That suggestion may be problematic if a Diameter server adds
>additional RADIUS compatible attributes to a Diameter message that
>contains attributes previously taken from RADIUS.  There is no way for
>a Diameter to RADIUS gateway to be sure if the attributes fit into a
>RADIUS packet.
>
>   Another option would be to add a "RADIUS" bit to the Diameter
>attribute.  Any attribute that came from a RADIUS to Diameter gateway
>would have that bit set, allowing later servers to handle them more
>appropriately.

We already have this.  It's the Origin-AAA-Protocol AVP (AVP Code 408)
RFC 4005, Section 9.3.6

>   I think this addresses Glen's comments.  It doesn't matter how large
>Diameter messages/attributes are if RADIUS servers never see that
>data.  Since the Diameter format is used by the RADIUS servers only to
>*generate* RADIUS compatible traffic, and not to receive Diameter
>traffic, any compatibility issue is pushed to the Diameter side of the
>protocol implementations.
>
>   Alan DeKok.
>
>--

Right, but I don't think that's actually the problem Glen is chasing, 
but I'll leave that to him.

Dave.

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

Delivery-date: Thu, 23 Mar 2006 23:50:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-vlan-01.txt 
Date: Thu, 23 Mar 2006 18:50:01 -0500

--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 Attributes for Virtual LAN and Priority Support
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-vlan-01.txt
	Pages		: 14
	Date		: 2006-3-23
	
This document proposes additional RADIUS (Remote Authentication Dial
   In User Service) attributes for dynamic Virtual LAN assignment and
   prioritization, for use by IEEE 802.1X authenticators.  These
   attributes are usable within either RADIUS or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-vlan-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-vlan-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-vlan-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-vlan-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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: Thu, 23 Mar 2006 06:51:05 +0000
Content-class: urn:content-classes:message
Subject: Radius Dyn auth MIBs with the updates
Date: Thu, 23 Mar 2006 12:20:17 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64E46.0AB5C8D0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C64E46.0AB5C8D0"

------_=_NextPart_002_01C64E46.0AB5C8D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
=20
I've attached the revised  Dyn Auth client and server drafts. Could you
please review if these are inline with your suggestions.
=20
Here is a brief summary of changes for your quick reference
=20
1. Replaced with "itself" in the cleint draft. Server draft was fine.

2. Added a new time stamp scalar. Juergen suggestion of having scalars
group is helpful here.

- Incremented the number of scalars in the Overview sections

- Referred to this new object while updating the counter objects=20

- Mentioned the same in Compliance

Here is the definition of the time stamp scalar. The same follows for
the other draft.

radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
          SYNTAX TimeTicks
          UNITS  "hundredths of a second"
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION

                "The time (in hundredths of a second) since the
                 DAC module was last re-initialized."
          ::=3D { radiusDynAuthClientScalars 3 }

Each counter object has got a new sentence that says the below.

"This counter may experience a discontinuity when the DAC module
(re)starts as indicated by the value of
radiusDynAuthClientCounterDiscontinuity."

3. "Port number 0 is invalid" mentioned for
radiusDynAuthServerClientPortNumber  object

4. Compliance statements now say that we only support IPv4 and IPV6 5.
InetAddress objects are updated with what InetAddressType object
determines the address

Here is the compliance statement and the new objects.

radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
             "The compliance statement for entities implementing
              the RADIUS Dynamic Authorization Client. Implementation
        of this module is for entities that support IPv6, or
        support IPv4 and IPv6."
       MODULE  -- this module
       MANDATORY-GROUPS { radiusDynAuthClientMIBGroup }

       OBJECT        radiusDynAuthServerAddressType
       SYNTAX        InetAddressType { ipv4(1), ipv6(2) }
       DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

       OBJECT        radiusDynAuthServerAddress
       SYNTAX        InetAddress (SIZE(4|16))=20
       DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

       GROUP              radiusDynAuthClientAuthOnlyGroup
       DESCRIPTION
             "Only required for Dynamic Authorization Clients that
              are supporting Service-Type attributes with value
              'Authorize-Only'."

=20
       GROUP              radiusDynAuthClientNoSessGroup
       DESCRIPTION
             "This group is not required in case the Dynamic
              Authorization Server can not easily determine whether
              a session exists or not (e.g., in case of a RADIUS
              proxy)."

       ::=3D { radiusDynAuthClientMIBCompliances 1 }

=20

Thanks

Nagi

=20

=20
=20
=20
=20

------_=_NextPart_002_01C64E46.0AB5C8D0
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2>All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial size=3D2>I've =
attached the=20
revised&nbsp; Dyn Auth client and&nbsp;server drafts. Could you please =
review if=20
these are inline with your suggestions.</FONT></SPAN></DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial size=3D2>Here =
is a brief=20
summary of changes&nbsp;for your quick reference</FONT></SPAN></DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial size=3D2><FONT=20
size=3D2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT><FONT face=3DArial =
size=3D2>1. Replaced=20
with "itself" in the cleint draft. Server draft was fine.</FONT></DIV>
<DIV>
<P><FONT face=3DArial size=3D2>2. Added a new time stamp scalar. Juergen =

suggestion&nbsp;<SPAN class=3D982173806-23032006>of having scalars group =
</SPAN>is=20
h<SPAN class=3D982173806-23032006>e</SPAN>lpful here<SPAN=20
class=3D982173806-23032006>.</SPAN></FONT></P>
<P><FONT><SPAN class=3D982173806-23032006></SPAN><FONT =
face=3DArial><FONT size=3D2>-=20
Incremented the number of scalars<SPAN class=3D982173806-23032006> in =
the Overview=20
sections</SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2>- Referred to this new object while =
updating=20
the counter objects</FONT></FONT><FONT face=3DArial size=3D2> =
</FONT></P>
<P><FONT face=3DArial size=3D2>- Mentioned the same in =
Compliance</FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D982173806-23032006>Here is =
the definition=20
of the time stamp scalar. The same follows for the other=20
draft.</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D982173806-23032006>radiusDynAuthClientCounterDiscontinuity=20
OBJECT-TYPE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX=20
TimeTicks<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
UNITS&nbsp;=20
"hundredths of a=20
second"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS=20
read-only<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS=20
current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D982173806-23032006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"The time (in hundredths of a second) since=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DAC module was last=20
re-initialized."<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; ::=3D {=20
radiusDynAuthClientScalars 3 }</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D982173806-23032006>Each =
counter object=20
has got a new sentence that says the below.</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D982173806-23032006>"This =
counter may=20
experience a&nbsp;discontinuity when the DAC module (re)starts =
as&nbsp;indicated=20
by the value =
of&nbsp;radiusDynAuthClientCounterDiscontinuity."</SPAN></FONT></P>
<P><FONT face=3DArial><FONT size=3D2>3. "Port number 0 is invalid"=20
mentioned&nbsp;<SPAN class=3D982173806-23032006>for=20
radiusDynAuthServerClientPortNumber&nbsp; =
object</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2>4. Compliance statement<SPAN=20
class=3D982173806-23032006>s</SPAN> now say that we only support IPv4 =
and IPV6 5.=20
InetAddress objects are updated with what InetAddressType object<SPAN=20
class=3D982173806-23032006> </SPAN></FONT></FONT><FONT face=3DArial=20
size=3D2>determines the address</FONT></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial size=3D2>Here is =
the compliance=20
statement and the new objects.</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2>radiusDynAuthClientMIBCompliance=20
MODULE-COMPLIANCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STATUS&nbsp;=20
current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
"The compliance statement for entities=20
implementing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
the RADIUS Dynamic Authorization Client.=20
Implementation<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of this =
module is=20
for entities that support IPv6, =
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
support IPv4 and IPv6."<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MODULE&nbsp; --=20
this module<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MANDATORY-GROUPS {=20
radiusDynAuthClientMIBGroup }</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;=20
radiusDynAuthServerAddressType<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; InetAddressType { ipv4(1), =
ipv6(2)=20
}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; "An=20
implementation is only required to support IPv4=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
globally unique IPv6 addresses."</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp; =
radiusDynAuthServerAddress<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; InetAddress (SIZE(4|16))=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; "An=20
implementation is only required to support IPv4=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
globally unique IPv6 addresses."</FONT></SPAN></P><SPAN=20
class=3D982173806-23032006><FONT face=3DArial size=3D2>
<P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
GROUP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
radiusDynAuthClientAuthOnlyGroup<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
"Only required for Dynamic Authorization Clients=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
are supporting Service-Type attributes with=20
value<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
'Authorize-Only'."</P>
<P>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
GROUP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
radiusDynAuthClientNoSessGroup<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
"This group is not required in case the=20
Dynamic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
Authorization Server can not easily determine=20
whether<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
a session exists or not (e.g., in case of a=20
RADIUS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
proxy)."</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D { =
radiusDynAuthClientMIBCompliances=20
1 }</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2>Thanks</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial =
size=3D2>Nagi</FONT></SPAN></P>
<P><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</P></FONT></SPAN></DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982173806-23032006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C64E46.0AB5C8D0--

------_=_NextPart_001_01C64E46.0AB5C8D0
Content-Type: text/plain;
	name="mib-client-15.txt"
Content-Transfer-Encoding: base64
Content-Description: mib-client-15.txt
Content-Disposition: attachment;
	filename="mib-client-15.txt"

------_=_NextPart_001_01C64E46.0AB5C8D0
Content-Type: text/plain;
	name="mib-server-15.txt"
Content-Transfer-Encoding: base64
Content-Description: mib-server-15.txt
Content-Disposition: attachment;
	filename="mib-server-15.txt"

------_=_NextPart_001_01C64E46.0AB5C8D0--

--
to unsubscribe send a message 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, 22 Mar 2006 21:36:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Location draft issues raised today 
Date: Wed, 22 Mar 2006 16:36:28 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> RADIUS has transported poorly formatted data, and made policy
> decisions on it for a very long time now.  I just don't see why
> location is so special that we have to enforce the RADIUS data
> model now.

I've avoided responding to many of your specific items of reasoning in
this message, because in this last paragraph it seems that you don't see
any value in having any kind of formalized RADIUS data model.  This
seems to contradict some of your previous postings.  Am I summarizing
your thoughts correctly here?  Or do you simply see location data as a
special case?

--
to unsubscribe send a message 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, 22 Mar 2006 20:50:42 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-04.txt 
Date: Wed, 22 Mar 2006 15:50:01 -0500

--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		: Dynamic Authorization Server MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-server-mib-04.txt
	Pages		: 27
	Date		: 2006-3-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-dynauth-server-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynauth-server-mib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

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

Envelope-to: [email-masked]
Delivery-date: Wed, 22 Mar 2006 17:57:40 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: RADIUS to Diameter gateways & extended attributes 
cc: [email-masked]
Date: Wed, 22 Mar 2006 13:05:29 -0500
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> I think the size related issue can be resolved in a much simpler way.
> Also note that it's not individual attributes that are the problem, as
> much as the total size of the attributes combined.

  Diameter to RADIUS gateways *already* have to enforce:

   a) per-attribute size for RADIUS-compatible Diameter attributes (1..255)
   b) total message size for RADIUS packets

  For *any* format of RADIUS extended attribute, Diameter to RADIUS
gateways will still have to enforce the above restrictions.

> So making the DIAMETER to RADIUS gateway to know what the maximum size
> is for each attribute does not help. It's the total response packet that
> may or may not fit after reencoding using any Extended Attribute
> format.

  Diameter to RADIUS gateways already have this problem when
administrators use Diameter attributes from the RADIUS space (1..255).
They have already implement solutions to this problem.

  Adding a new RADIUS extended attribute changes nothing, except that
the above restrictions must also be applied to the new attributes.

> If the DIAMETER home server allows requests that ultimately come from a
> RADIUS client, then it must expect that any response attribute that
> RADIUS allows to be ignored, can be ignored, with the session being
> allowed to start -- unless the proxy chain and the NAS make certain
> promises in the request regarding the passing and applying of response
> attributes.

  Yes.  It appears we need information in the Diameter message that
"this message is coming from, or going to, a RADIUS system".  I don't
know if Diameter already has that capability.  If not, it would make
the above decisions much easier for Diameter servers.

> The problem does not lie on the attribute number level. A short IP
> filtering attribute would be perfectly fine, whereas a longer one would
> not. Would you want to prohibit the gatewaying of any filtering
> attributes a priori, just because they *can* be longer than the RADIUS
> limit of 4096 minus some?

  No.  But the Diameter server must be able to make an informed
decision.  Failing that, Diameter to RADIUS gateways become almost
impossible to implement robustly.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 22 Mar 2006 17:44:18 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: Location draft issues raised today 
cc: [email-masked]
Date: Wed, 22 Mar 2006 12:51:53 -0500
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> I agree that it would support the packing as it is, but I think the
> overriding criterium is whether or not the server wants access to
> individual members in order to apply administrator defined policy.

  I am hesitant to make gratuitous changes to existing location data
structures just to satisfy RADIUS historical practices.  Doing so
would affect interoperability and implementation.  It would make
location-based systems harder to implement, because of the pointless
translation from location structures to RADIUS-friendly structures.

  In addition, there is presumably already code to parse and process
the location data structures.  RADIUS implementations should be able
to re-use that code to abstract access to the information they need
for policy.

  This is *no* different than implementing EAP.  EAP implementors were
not forced to re-pack their data into RADIUS friendly structures.  I
do not believe it's necessary to require the location structures to be
re-pack, either.

> The repacking by the RADIUS client can be well defined and nonambiguous.
> I don't see any problem with that.

  It's more code.  It's gratuitous re-packing just to make location
data fit into the RADIUS data model (such as it is).

> It's in our scope anyway. It's not that "if there's any other encoding
> for this information, in any other protocol, we have nothing to say
> anymore". This is also what I seemed to hear from Bert as well as
> Bernard.

  It's not "if there's any other encoding", but: If RADIUS is being
(ab)used as a transport protocol for data, it should *not* mangle that
data.

  Nearly every transport implementation that has massaged the data it
transported has created bugs, interoperability issues, implementation
problems, and security breaches.  Much as I think the location
structure is a *terrible* one, I think mangling the data causes more
problems than it solves.

> It depends on whether there's any meaning to be attached to the elements
> *at our level*, that is, the RADIUS proxy or endpoint.

  Like EAP?  While the canonical diagrams of RADIUS to EAP
authenticators show separate RADIUS & EAP systems, in reality they're
almost always implemented in the RADIUS server.  RADIUS is just
transport for EAP data, which people *do* use to make policy
decisions.

  There are precedents for RADIUS being used as a transport protocol
for data that doesn't match the RADIUS data model.  There are
precedents for RADIUS servers implementing policy based on that data.

> It depends on whether there's any meaning to be attached to the elements
> *at our level*, that is, the RADIUS proxy or endpoint.

  Like the ARAP attributes?  Or the Login-LAT-* attributes?  RADIUS
has transported poorly formatted data, and made policy decisions on it
for a very long time now.  I just don't see why location is so special
that we have to enforce the RADIUS data model now.

  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, 22 Mar 2006 08:34:37 +0000
Date: Wed, 22 Mar 2006 09:34:27 +0100
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS to Diameter gateways & extended attributes
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 21, 2006 at 02:08:11PM -0500, Alan DeKok wrote:

>   That is, it doesn't matter so much that Diameter can carry much more
> traffic per attribute/message than RADIUS can, because that is not the
> purpose behind the use of the Diameter attribute format.  If that is
> true, we then have to ensure that Diameter to RADIUS gateways don't
> pass large Diameter attributes/messages to RADIUS.
> 
>   Since we already have Diameter to RADIUS gateways that perform this
> enforcement, it would appear that this worry is largely not a problem
> in practice.
> 
>   However... with the advent of many more RADIUS attributes being
> carried in Diameter, it would be good to enable Diameter to RADIUS
> gateways to tell which attributes *can* fit into RADIUS, and which
> cannot.  One suggestion in the "extended attribute" subgroup was to
> allocate the Diameter-format RADIUS attributes from a subset of the
> Diameter space.  The gateways could then trivially tell which
> attributes are RADIUS compatible.

I think the size related issue can be resolved in a much simpler way.
Also note that it's not individual attributes that are the problem, as
much as the total size of the attributes combined.

So making the DIAMETER to RADIUS gateway to know what the maximum size
is for each attribute does not help. It's the total response packet that
may or may not fit after reencoding using any Extended Attribute
format.

However, a DIAMETER client has a concept of clients NAKing server
responses, if I remember correctly, because there is a class of
attributes for which a server may set the M bit, but that are not
required to be supported on the NAS by the base specification or NASREQ. 

Because DIAMETER servers already have to handle such situations
gracefully, having a gateway NAK overlength responses, longest
attributes first would seem a good approach.

Alternatively, the DIAMETER gateway could first retry by ignoring all
non-M attribute from the DIAMETER response to see if the recoded RADIUS
response fits the limit. If it still doesn't fit, the gateway will still
have to NAK the response.

But if the home DIAMETER server wants to know *in advance* that the
policy it is about to send will actually be applied in full, the whole
generic issue of NAS hints and promises appears, and that's a generic
problem that has little to do with DIAMETER or gatewaying per se.

A DIAMETER gateway in that respect is nothing but a special case of an
response attribute filtering proxy. And all RADIUS proxies do that in
some form or another. This has come up before, and we never finished
that discussion, although I still think that the concept of a client's
promises-to-apply, however encoded, would solve the problem.

If the DIAMETER home server allows requests that ultimately come from a
RADIUS client, then it must expect that any response attribute that
RADIUS allows to be ignored, can be ignored, with the session being
allowed to start -- unless the proxy chain and the NAS make certain
promises in the request regarding the passing and applying of response
attributes.

>   That suggestion may be problematic if a Diameter server adds
> additional RADIUS compatible attributes to a Diameter message that
> contains attributes previously taken from RADIUS.  There is no way for
> a Diameter to RADIUS gateway to be sure if the attributes fit into a
> RADIUS packet.
> 
>   Another option would be to add a "RADIUS" bit to the Diameter
> attribute.  Any attribute that came from a RADIUS to Diameter gateway
> would have that bit set, allowing later servers to handle them more
> appropriately.
> 
>   I think this addresses Glen's comments.  It doesn't matter how large
> Diameter messages/attributes are if RADIUS servers never see that
> data.  Since the Diameter format is used by the RADIUS servers only to
> *generate* RADIUS compatible traffic, and not to receive Diameter
> traffic, any compatibility issue is pushed to the Diameter side of the
> protocol implementations.

The problem does not lie on the attribute number level. A short IP
filtering attribute would be perfectly fine, whereas a longer one would
not. Would you want to prohibit the gatewaying of any filtering
attributes a priori, just because they *can* be longer than the RADIUS
limit of 4096 minus some?

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 22 Mar 2006 08:14:05 +0000
Date: Wed, 22 Mar 2006 09:13:22 +0100
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Location draft issues raised today
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 21, 2006 at 02:43:23PM -0500, Alan DeKok wrote:

>   There were concerns rasied in the meeting today about the encoding
> of location data in RADIUS attributes.  I'll expand on my comments here:
> 
>  - If the encoding of the location information is taken from a
> normitive reference (as suggested in the WG meeting), then the packing
> of that information should be outside of the scope of RADEXT.  The
> description of the complex encoding in the draft should be replaced by
> a normitive reference to another document.
> 
>   That would resolve all of the concerns around complex attribute
> encodings in RADIUS.

I agree that it would support the packing as it is, but I think the
overriding criterium is whether or not the server wants access to
individual members in order to apply administrator defined policy.

If so, an encoding using multiple attributes, however grouped (if needed
at all; a request only contains at most one instance of location
information if I understand correctly), would be desireable over
packing, even if such a packing is standardized for another protocol.

The repacking by the RADIUS client can be well defined and nonambiguous.
I don't see any problem with that.

Note that we can't foresee all future policies that servers or their
administrators would wish to execute. It's better to err on the side of
caution (splitting in multiple attributes where that's not really
necessary) than on the other side, as that would require servers to be
updated with GEOPRIV-specific parsing code as soon as they would want to
support location-specific authorisations.

In this case, if there is any reasonable use for individual member
fields, they should use separate attributes, in my opinion.

>  - If, on the other hand, the encoding is specific to these attributes
> and occurs nowhere else, then the packing is within the scope of
> RADEXT, and the concerns raised should be addressed by the document
> authors.

It's in our scope anyway. It's not that "if there's any other encoding
for this information, in any other protocol, we have nothing to say
anymore". This is also what I seemed to hear from Bert as well as
Bernard.

It depends on whether there's any meaning to be attached to the elements
*at our level*, that is, the RADIUS proxy or endpoint.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 21 Mar 2006 20:50:23 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-04.txt 
Date: Tue, 21 Mar 2006 15:50:02 -0500

--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		: Dynamic Authorization Client MIB
	Author(s)	: S. De Cnodder, et al.
	Filename	: draft-ietf-radext-dynauth-client-mib-04.txt
	Pages		: 28
	Date		: 2006-3-21
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-dynauth-client-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynauth-client-mib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

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

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Mar 2006 19:36:10 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Location draft issues raised today 
Date: Tue, 21 Mar 2006 14:43:23 -0500
Message-Id: <[email-masked]>

  There were concerns rasied in the meeting today about the encoding
of location data in RADIUS attributes.  I'll expand on my comments here:

 - If the encoding of the location information is taken from a
normitive reference (as suggested in the WG meeting), then the packing
of that information should be outside of the scope of RADEXT.  The
description of the complex encoding in the draft should be replaced by
a normitive reference to another document.

  That would resolve all of the concerns around complex attribute
encodings in RADIUS.

 - If, on the other hand, the encoding is specific to these attributes
and occurs nowhere else, then the packing is within the scope of
RADEXT, and the concerns raised should be addressed by the document
authors.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Mar 2006 19:01:03 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: RADIUS to Diameter gateways & extended attributes
Date: Tue, 21 Mar 2006 14:08:11 -0500
Message-Id: <[email-masked]>

  Some issues were raised during the WG meeting today.  I'll try to
address them here.

  The purpose behind using the Diameter format to carry extended
RADIUS attributes is to simplify the work done by RADIUS to Diameter
gateways.  As a result, any issue of Diameter to RADIUS gatewaying and
attribute/message size is largely out of scope.

  That is, it doesn't matter so much that Diameter can carry much more
traffic per attribute/message than RADIUS can, because that is not the
purpose behind the use of the Diameter attribute format.  If that is
true, we then have to ensure that Diameter to RADIUS gateways don't
pass large Diameter attributes/messages to RADIUS.

  Since we already have Diameter to RADIUS gateways that perform this
enforcement, it would appear that this worry is largely not a problem
in practice.

  However... with the advent of many more RADIUS attributes being
carried in Diameter, it would be good to enable Diameter to RADIUS
gateways to tell which attributes *can* fit into RADIUS, and which
cannot.  One suggestion in the "extended attribute" subgroup was to
allocate the Diameter-format RADIUS attributes from a subset of the
Diameter space.  The gateways could then trivially tell which
attributes are RADIUS compatible.

  That suggestion may be problematic if a Diameter server adds
additional RADIUS compatible attributes to a Diameter message that
contains attributes previously taken from RADIUS.  There is no way for
a Diameter to RADIUS gateway to be sure if the attributes fit into a
RADIUS packet.

  Another option would be to add a "RADIUS" bit to the Diameter
attribute.  Any attribute that came from a RADIUS to Diameter gateway
would have that bit set, allowing later servers to handle them more
appropriately.

  I think this addresses Glen's comments.  It doesn't matter how large
Diameter messages/attributes are if RADIUS servers never see that
data.  Since the Diameter format is used by the RADIUS servers only to
*generate* RADIUS compatible traffic, and not to receive Diameter
traffic, any compatibility issue is pushed to the Diameter side of the
protocol implementations.

  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, 21 Mar 2006 15:21:58 +0000
Content-class: urn:content-classes:message
Subject: My Genart review issue on RADIUS Digest
Date: Tue, 21 Mar 2006 17:21:28 +0200
From: <[email-masked]>
To: <[email-masked]>

Just for the record, my issue has be resolved, so my issue can be
cleared.

John

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

Delivery-date: Tue, 21 Mar 2006 14:26:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF 65 slides available
Date: Tue, 21 Mar 2006 06:26:03 -0800

The slides from the IETF 65 RADEXT meeting are now available online here:
http://www.drizzle.com/~aboba/IETF65/radext/

--
to unsubscribe send a message 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, 21 Mar 2006 12:18:34 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Congdon, Paul T \(ProCurve\)'" <[email-masked]>, "'Greg Weber \(gdweber\)'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Tue, 21 Mar 2006 04:16:47 -0800

Tagged VLANs seems ok (and it fits in the diagrams).  

-----Original Message-----
From: Congdon, Paul T (ProCurve) [mailto:[email-masked]] 
Sent: Monday, March 20, 2006 10:45 PM
To: Bernard Aboba; Greg Weber (gdweber)
Cc: [email-masked]
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types

Yes, I remember the discussion about using ASCII representations of a
flag.

How about "Tagged VLANs" or "Tagged VLANs Flag" for a field name?

To me, "VLAN Flag" is confusing. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, March 20, 2006 10:08 PM
> To: Congdon, Paul T (ProCurve); 'Greg Weber (gdweber)'
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
> 
> Here are some thoughts:
> 
> 1. The values of 0x31 and 0x32 translate to ASCII '1' and 
> '2'.  This is useful for the Egress-VLAN-Name attribute, 
> since this allows the attribute (defined as type String) to 
> be entered easily.  Changing the values to
> 0x01 and 0x00 would it harder to input the attribute, so I 
> don't think this change is a good idea.  
> 
> 2. You are right that this variable is not really a Flag, and 
> others have stated it is not a Tag (at least in the RFC 2868 
> sense). Given this, I'm somewhat concerned about calling it a 
> 'VLAN Tag Flag'.  What do other people think? 
> 
> 3. Could we perhaps call it the "Tagging" field? 
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Congdon, 
> Paul T (ProCurve)
> Sent: Monday, March 20, 2006 5:36 PM
> To: Greg Weber (gdweber); Bernard Aboba
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
> 
> The name "VLAN Flag" is miss leading.  There is certainly a 
> VLAN present.  The question is whether the VLAN is tagged or 
> not.  I understand the confusion with Radius tags - though 
> people who understand VLANs and would be using this attribute 
> probably wouldn't have a problem.
> 
> If you must change the field name - which I'm not really in 
> support of - I suggest calling it "VLAN Tag Flag" and going 
> with the 1 and 0 symantics of TRUE and FALSE.
> 
> 

--
to unsubscribe send a message 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, 21 Mar 2006 06:45:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Mon, 20 Mar 2006 22:44:56 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Greg Weber (gdweber)" <[email-masked]>
Cc: <[email-masked]>

Yes, I remember the discussion about using ASCII representations of a
flag.

How about "Tagged VLANs" or "Tagged VLANs Flag" for a field name?

To me, "VLAN Flag" is confusing.=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, March 20, 2006 10:08 PM
> To: Congdon, Paul T (ProCurve); 'Greg Weber (gdweber)'
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
>=20
> Here are some thoughts:
>=20
> 1. The values of 0x31 and 0x32 translate to ASCII '1' and=20
> '2'.  This is useful for the Egress-VLAN-Name attribute,=20
> since this allows the attribute (defined as type String) to=20
> be entered easily.  Changing the values to
> 0x01 and 0x00 would it harder to input the attribute, so I=20
> don't think this change is a good idea. =20
>=20
> 2. You are right that this variable is not really a Flag, and=20
> others have stated it is not a Tag (at least in the RFC 2868=20
> sense). Given this, I'm somewhat concerned about calling it a=20
> 'VLAN Tag Flag'.  What do other people think?=20
>=20
> 3. Could we perhaps call it the "Tagging" field?=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Congdon,=20
> Paul T (ProCurve)
> Sent: Monday, March 20, 2006 5:36 PM
> To: Greg Weber (gdweber); Bernard Aboba
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
>=20
> The name "VLAN Flag" is miss leading.  There is certainly a=20
> VLAN present.  The question is whether the VLAN is tagged or=20
> not.  I understand the confusion with Radius tags - though=20
> people who understand VLANs and would be using this attribute=20
> probably wouldn't have a problem.
>=20
> If you must change the field name - which I'm not really in=20
> support of - I suggest calling it "VLAN Tag Flag" and going=20
> with the 1 and 0 symantics of TRUE and FALSE.
>=20
>=20

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

Delivery-date: Tue, 21 Mar 2006 06:08:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Congdon, Paul T \(ProCurve\)'" <[email-masked]>, "'Greg Weber \(gdweber\)'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Mon, 20 Mar 2006 22:08:05 -0800

Here are some thoughts:

1. The values of 0x31 and 0x32 translate to ASCII '1' and '2'.  This is
useful for the Egress-VLAN-Name attribute, since this allows the attribute
(defined as type String) to be entered easily.  Changing the values to
0x01 and 0x00 would it harder to input the attribute, so I don't think this 
change is a good idea.  

2. You are right that this variable is not really a Flag, and others have
stated it is not a Tag (at least in the RFC 2868 sense). Given this, I'm
somewhat concerned about calling it a 'VLAN Tag Flag'.  What do other people
think? 

3. Could we perhaps call it the "Tagging" field? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Congdon, Paul T (ProCurve)
Sent: Monday, March 20, 2006 5:36 PM
To: Greg Weber (gdweber); Bernard Aboba
Cc: [email-masked]
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types

The name "VLAN Flag" is miss leading.  There is certainly a VLAN
present.  The question is whether the VLAN is tagged or not.  I
understand the confusion with Radius tags - though people who understand
VLANs and would be using this attribute probably wouldn't have a
problem.

If you must change the field name - which I'm not really in support of -
I suggest calling it "VLAN Tag Flag" and going with the 1 and 0
symantics of TRUE and FALSE.

--
to unsubscribe send a message 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, 21 Mar 2006 05:59:01 +0000
Content-class: urn:content-classes:message
Subject: RE: MIB Counters discontinuity
Date: Tue, 21 Mar 2006 11:28:24 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Sounds good and thanks to all of you. We'll address this issue in the
next revision.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Tuesday, March 21, 2006 1:08 AM
To: [email-masked]
Subject: RE: MIB Counters discontinuity

Bert Wijnen writes...

> From your story, it seems to me that
> you need your own Discontinuity Timer.

I was discussing this issue with Dave Harrington, over lunch.  Dave
concurred with the suggestion that these MIBs contain their own
discontinuity timestamp, rather than relying on the sysUpTime object or
using sysORUpTime.

It should be sufficient for each RADIUS client entity or server entity
to maintain a single up time.

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

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

Delivery-date: Tue, 21 Mar 2006 01:38:16 +0000
To: [email-masked]
From: John Schnizlein <[email-masked]>
Subject: Fwd: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute"
Date: Mon, 20 Mar 2006 19:37:57 -0600

--Apple-Mail-1--758363358
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Begin forwarded message:

> From: "Bernie Volz \(volz\)" <[email-masked]>
> Date: March 20, 2006 6:25:11 PM CST
> To: "John Schnizlein \(jschnizl\)" <[email-masked]>
> Subject: RE: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated 
> IPv6 PrefixAttribute"
>
> John:
>
> Feel free to forward this to the WG!
>
> I just read the draft and it looks fine to me; I support its
> publication.
>
> There are a few minor nits though:
>
> ** 1. Why "another" in the second sentence of the introduction:
>
> ---
> 1.  Introduction
>
>    The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated 
> to
>    the user.  For example, the prefix in a Delegated-IPv6-Prefix
>    attribute can be delegated to another node through DHCP Prefix
>    Delegation [2].
> ---
>
> Would not just "... can be delegated to a node through DHCP ..." be
> sufficient?
>
> ----
>
> ** 2. And further in the introduction:
>
> ---
>    The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and
>    can appear multiple times.  It MAY be used in an Access-Request
>    packet as a hint by the NAS to the server that it would prefer these
>    prefix(es), but the server is not required to honor the hint.
> ---
>
> The table in section 3 lists Accounting Request (0+). So, it MAY also
> appear there.
>
> ----
>
> ** 3. The use of bytes should be replaced by octets? This was a comment
> I got on a recent round of documents from the IESG, so they'll raise it
> and best to fix before it goes on to them? See section 3.
>
> ---
>
>    Note that the prefix field is only required to be long enough to 
> hold
>    the prefix bits and can be shorter than 16 bytes.  Any bits in the
>    prefix field that are not part of the prefix MUST be zero.
>
> ---
>
> ** 4. You might add "the":
>
>    In this table 0 indicates that an attribute MUST NOT be present in
>    the packet and 0+ means that zero or more instances of this 
> attribute
>    MAY be present in the packet.
>                      ^^^
>
> Best regards,
>
> - Bernie
>

--Apple-Mail-1--758363358
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>"Bernie Volz \(volz\)" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
20, 2006 6:25:11 PM CST

<bold><color><param>0000,0000,0000</param>To: </color></bold>"John
Schnizlein \(jschnizl\)" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>RE: [dhcwg]
Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute"

</bold>

John:

Feel free to forward this to the WG!

I just read the draft and it looks fine to me; I support its

publication.

There are a few minor nits though:

** 1. Why "another" in the second sentence of the introduction:

---

1.  Introduction

   The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated
to

   the user.  For example, the prefix in a Delegated-IPv6-Prefix

   attribute can be delegated to another node through DHCP Prefix

   Delegation [2].

---

Would not just "... can be delegated to a node through DHCP ..." be

sufficient?

----

** 2. And further in the introduction:

---

   The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and

   can appear multiple times.  It MAY be used in an Access-Request

   packet as a hint by the NAS to the server that it would prefer these

   prefix(es), but the server is not required to honor the hint.

---

The table in section 3 lists Accounting Request (0+). So, it MAY also

appear there.

----

** 3. The use of bytes should be replaced by octets? This was a comment

I got on a recent round of documents from the IESG, so they'll raise it

and best to fix before it goes on to them? See section 3.

---

   Note that the prefix field is only required to be long enough to
hold

   the prefix bits and can be shorter than 16 bytes.  Any bits in the

   prefix field that are not part of the prefix MUST be zero.

---

** 4. You might add "the":

   In this table 0 indicates that an attribute MUST NOT be present in

   the packet and 0+ means that zero or more instances of this
attribute

   MAY be present in the packet.

                     ^^^

Best regards,

- Bernie

</excerpt>
--Apple-Mail-1--758363358--

--
to unsubscribe send a message 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, 21 Mar 2006 01:36:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Mon, 20 Mar 2006 17:36:17 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

The name "VLAN Flag" is miss leading.  There is certainly a VLAN
present.  The question is whether the VLAN is tagged or not.  I
understand the confusion with Radius tags - though people who understand
VLANs and would be using this attribute probably wouldn't have a
problem.

If you must change the field name - which I'm not really in support of -
I suggest calling it "VLAN Tag Flag" and going with the 1 and 0
symantics of TRUE and FALSE.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Friday, March 17, 2006 9:09 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
>=20
> =20
> Now the VLAN-01 strawman says:
>       The VLAN Flag field is one octet in length,=20
>       and indicates whether the frames on the VLAN=20
>       are tagged (0x31) or untagged (0x32).=20
>=20
> But it doesn't say *how* the flag field indicates tagged vs.=20
> untagged.  With the attribute name being VLAN Flag, I would=20
> think that attribute's values would be 1 or 0.  Do I indicate=20
> 'tagged' by setting the value of VLAN Flag to 1 or to 0x31?
>=20
> Greg
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Thursday, March 16, 2006 1:15 PM
> > To: [email-masked]
> > Subject: Proposed Resolution to Issue 180: Misuse of Data Types
> >=20
> > The text of Issue 180 (and some of the subsequent discussion) is=20
> > enclosed below.
> >=20
> > The proposed resolution is to change "VLAN Tag" to "VLAN Flag"=20
> > everywhere in the document.
> >=20
> > In looking at the mailing list discussion, I did not detect=20
> consensus=20
> > for making other changes.
> >=20
> > --------------------------------------------------------------
> > --------------------------------------
> > Issue 180: Misuse of Data Types
> > Submitter name: Dave Nelson
> > Submitter email address: [email-masked] Date first=20
> submitted:=20
> > March 14, 2006
> > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html
> > Document: VLAN/Priority -00
> > Comment type: 'T'echnical
> > Priority: '1' Should fix
> > Section: 2.1.  Egress-VLANID
> > Rationale/Explanation of issue:
> >=20
> > I had previously raised this issue, and the resolution was we could=20
> > use a RADIUS data type of Integer, because only the VLANID (12-bit)=20
> > portion would be used.
> > Thus, this object could be thought  of as a range-limited integer.=20
> > Since I see that we still have the VLAN Tag fields, that resolution=20
> > falls apart.  I claim that this data object is not an Integer.
> >=20
> > Someone offered the suggestion that Integers are not simply the=20
> > mathematical definition, i.e. the positive  and negative=20
> whole numbers=20
> > and zero, that we all learned in high school. With all due respect,
> >=20
> > I think that's patently wrong. It is true that one can=20
> write programs=20
> > that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as=20
> packed data=20
> > structures using mask, bit-field, shift and rotate operations.
> >=20
> > I still claim that those data structures are *not* integers simply=20
> > because they can be packed within the computer memory=20
> storage that is=20
> > also used by integers.
> > Hopefully, there
> > is more to data modeling  than the storage length in bits. :-)
> >=20
> > We are currently having a debate on the RADEXT WG list=20
> about the issue=20
> > of derived data types, and no  consensus has yet been reached.
> > However, until
> > such a consensus is reached, it seems most appropriate  to=20
> follow the=20
> > existing practice of defining derived data types as=20
> Strings, with the=20
> > bit-fields described in the text. I think that over-loading base=20
> > RADIUS data types with new meanings is inappropriate.
> >=20
> > Given the relative timing of WGLC on this draft and the emerging=20
> > consensus on RADIUS Attribute Design Guidelines, I think=20
> this is the=20
> > best compromise.
> >=20
> > Requested change:
> >=20
> > OLD:
> >=20
> > Integer
> >=20
> > The Integer field is four octets in length. The format is described=20
> > below:
> >=20
> > 0                   1                   2                   3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | VLAN Tag      |      Pad              |       VLANID          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >=20
> > The VLAN Tag field is one octet in length, and indicates=20
> whether the=20
> > frames on the VLAN are tagged (0x31) or untagged (0x32).=20
> The Pad field=20
> > is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in=20
> > length and contains the [IEEE-802.1Q] VLAN VID value.
> >=20
> > NEW:
> >=20
> > String
> >=20
> > The String field is four octets in length. The format is described=20
> > below:
> >=20
> > 0                   1                   2                   3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | VLAN Tag      |      Pad              |       VLANID          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >=20
> > The VLAN Tag field is one octet in length, and indicates=20
> whether the=20
> > frames on the VLAN are tagged (0x31) or untagged (0x32).=20
> The Pad field=20
> > is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in=20
> > length and contains the [IEEE-802.1Q] VLAN VID value.
> >=20
> > Section: 2.3. Egress-VLAN-Name
> > Rationale/Explanation of issue:
> >=20
> > I'm rather uncomfortable with the usage of the VLAN Tag=20
> field, as it=20
> > seems to be at variance with the emerging WG consensus on=20
> complex or=20
> > structured data types. Once we standardize this usage,=20
> there will be=20
> > one more precedent in a RADIUS RFC to support ad-hoc data typing.
> > If that's what RADEXT ultimately recommends, then this will=20
> be fine.=20
> > If the recommendation is to use a more formal method of aggregating=20
> > structured data, this will be one more anomaly.
> >=20
> > VLAN Tag
> >=20
> > The VLAN tag field is one octet in length, and indicates=20
> whether the=20
> > frames on the VLAN are tagged (0x31) or untagged (0x32).
> >=20
> > Requested change:
> >=20
> > I have no idea what (if any change) to request. Chalk this=20
> comment up=20
> > as my personal lament over the process that RADEXT has followed --=20
> > delaying consensus on attributes design to the point where we are=20
> > standardizing new attributes using complex data types prior=20
> to having=20
> > defined the design guidelines for complex data types.
> >=20
> > Section 2.4 User-Priority-Table
> > Rationale/Explanation of issue:
> >=20
> > With all due deference to the well understood "array -=20
> string duality"=20
> > we find in programming languages such as C, I think that=20
> expressing a=20
> > attribute whose value is an array in the form of a RADIUS=20
> String type=20
> > is unfortunate, for the reasons expressed above.
> >=20
> > Requested change:
> >=20
> > (See above.)
> >=20
> > The only way that I see to actually resolve my data typing / data=20
> > modeling concerns is to delay sending any RADEXT work item=20
> that uses=20
> > derived data types to the IESG until after we have sent the RADIUS=20
> > Design Guidelines and RADIUS Extended Attributes I-Ds to=20
> the IESG, and=20
> > that approach is not compatible with our milestones.
> >=20
> > [Glen Zorn]
> > With all due respect, I think that you are the one doing the
> > overloading:=20
> > RFC 2568 says
> >=20
> > 	integer   32 bit unsigned value, most significant octet first.
> >=20
> > That's it.  No range, no interpretation, nothing else.
> >=20
> > [Emile Van Bergen]
> > >I see nothing that indicates this data type is anything=20
> other than an=20
> > >integer, typically expressed in a C language declaration=20
> as "unsigned=20
> > >long".
> >=20
> > You're completely correct. And in the case of the VLAN attribute, it
> > *does* contain an unsigned integer value, one that's calculated as=20
> > follows:
> >=20
> > value =3D vlanflag * 16777216 + vlanid
> >=20
> > The reverse goes as follows:
> >=20
> > vlanflag =3D value / 16777216
> > vlanid =3D value % 16777216
> >=20
> > (where
> > * denotes unsigned integer multiplication,
> > + denotes unsigned integer addition,
> > / denotes unsigned integer division and % denotes taking=20
> the reminder=20
> > of an unsigned integer division, all to be carried out on unsigned=20
> > integers in the range 0 .. 2**32-1)
> >=20
> > I'm not believing that people on this list would have to be=20
> explained=20
> > that shifting and masking bits are *not* magic operations=20
> that you can=20
> > only perform if you program in assembly (or its portable=20
> flavour, C),=20
> > but that those are normal mathematical operations on normal=20
> integers:
> > multiply and take remainder (by powers of 2).
> >=20
> > You can do that, I think, even in Java, SAP/r3, XSLT, SQL and=20
> > whatever.
> > This whole issue has nothing whatsoever to do with C structures.
> >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [email-masked] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 20 Mar 2006 20:36:01 +0000
Cc: [email-masked]
From: John Schnizlein <[email-masked]>
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Mon, 20 Mar 2006 14:35:21 -0600
To: "Bernard Aboba" <[email-masked]>

I have read the draft and support its advancement to RFC.

John

On Mar 3, 2006, at 2:12 PM, Bernard Aboba wrote:

> This is an announcement of RADEXT WG last call on the "RADIUS  
> Delegated-IPv6 Prefix Attribute"
> document, prior to sending this document on to the IESG for  
> consideration as a Proposed
> Standard.
>
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated- 
> prefix-00.txt
>
> RADEXT WG last call will last until Monday March 27, 2006.  Please  
> send your
> comments to the RADEXT WG list ([email-masked]) in the format  
> described
> on the RADEXT Issues List:
> http://www.drizzle.com/~aboba/RADEXT/
>
> Since all RADEXT WG last calls require at least 5 reviewers in order  
> to advance
> the document, please respond indicating that you have read the  
> document and
> find it acceptable, even if you have no issues to file.

--
to unsubscribe send a message 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, 20 Mar 2006 20:34:04 +0000
To: [email-masked]
Cc: Mark Stapp <[email-masked]>
Subject: Fwd: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
From: John Schnizlein <[email-masked]>
Date: Mon, 20 Mar 2006 14:33:50 -0600

--Apple-Mail-4--776610796
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

forwarded on behalf of interested community on the DHC mailing list

Begin forwarded message:

> From: Mark Stapp <[email-masked]>
> Date: March 20, 2006 2:27:28 PM CST
> To: John Schnizlein <[email-masked]>
> Subject: Re: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated 
> IPv6 Prefix Attribute"
>
> I have read the delegated prefix draft and have no objection.
>
> -- Mark Stapp

--Apple-Mail-4--776610796
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

forwarded on behalf of interested community on the DHC mailing list

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Mark Stapp <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
20, 2006 2:27:28 PM CST

<bold><color><param>0000,0000,0000</param>To: </color></bold>John
Schnizlein <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Re: [dhcwg]
Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"

</bold>

I have read the delegated prefix draft and have no objection.

-- Mark Stapp

</excerpt>
--Apple-Mail-4--776610796--

--
to unsubscribe send a message 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, 20 Mar 2006 19:58:42 +0000
Content-class: urn:content-classes:message
Subject: Information for remote participants
Date: Mon, 20 Mar 2006 14:58:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The online meeting materials for RADEXT (and other WGs) are being posted
at:

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
5

under the respective WG name.

The streaming audio for IETF-65 sessions may be accessed at:

http://videolab.uoregon.edu/events/ietf/

The Jabber Rooms for IETG Working Groups can be located at:

http://www.ietf.org/meetings/text_conf.html

The jabber server name is "rooms.jabber.ietf.org".  The room name for
RADEXT is "radext".

It would be helpful if anyone who plans to remotely participate in the
RADEXT session, starting Tuesday at 9:00 AM Central Standard Time, would
reply to me directly so that I can attempt to ensure that we have a
Jabber Scribe available to channel questions from remote participants.=20

-- Dave Nelson

--
to unsubscribe send a message 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, 20 Mar 2006 19:38:20 +0000
Content-class: urn:content-classes:message
Subject: RE: MIB Counters discontinuity
Date: Mon, 20 Mar 2006 14:37:34 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bert Wijnen writes...

> From your story, it seems to me that
> you need your own Discontinuity Timer.

I was discussing this issue with Dave Harrington, over lunch.  Dave
concurred with the suggestion that these MIBs contain their own
discontinuity timestamp, rather than relying on the sysUpTime object or
using sysORUpTime.

It should be sufficient for each RADIUS client entity or server entity
to maintain a single up time.

--
to unsubscribe send a message 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, 20 Mar 2006 15:55:12 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], "Nagi Reddy Jonnala (njonnala)" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/ser ver mibs structure)
Date: Mon, 20 Mar 2006 16:54:36 +0100

>From your story, it seems to me that
you need your own Discontinuity Timer.

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, March 20, 2006 07:52
> To: Nagi Reddy Jonnala (njonnala)
> Cc: [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; Dan Romascanu (E-mail)
> Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth
> client/server mibs structure)
> 
> 
> >>>
> >>>"This counter may experience discontinuity when the Dynamic 
> >>>Authorization Client (DAC) module is (re)started".
> >>
> >>Why only the DAC module?
> > 
> > 
> > IMO, in theory, a DAC/DAS can be restarted regardless of the system
> > restart(or sysUpTime). A similar statement is applicable to DAS
> > Mib/module.
> > 
> 
> Is it enough bu saying that there is a discontinuity at DAC or DAS 
> module restart or is there then also a need for a scalar that 
> contains 
> the value of sysUpTime at the time the discontinuity happened? For 
> implementations where the DAC or DAS cannot restart without that the 
> whole system restarts, this will always contain zero. This 
> looks better 
> to me but then the case where counters survive a restart 
> (e.g., if they 
> are put in persistent memory) is not possible anymore. I am 
> not really 
> interested in that case since these counters are not so 
> important that 
> they have to survive a restart. Introducing such an object would also 
> mean that when the management application restarts (sysUpTime 
> is zero), 
> then also the counters have to be reset even though the DAC or DAS 
> module might not have restarted (which is no problem for me).
> 
> So, what is now the preference:
> 
> 1) stating for each counter that it may experience a 
> discontinuity when 
> the DAC or DAS module (re)starts.
> 2) introducing such a scalar
> 3) use sysORUpTime instead
> 
> Thanks,
> Stefaan
> 
> 
> > Thanks
> > Nagi.
> > 
> > 
> >>/js
> >>
> >>-- 
> >>Juergen Schoenwaelder		    International 
> University Bremen
> >><http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> >>28725 Bremen, Germany
> > 
> > 
> 

--
to unsubscribe send a message 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, 20 Mar 2006 15:21:03 +0000
Date: Mon, 20 Mar 2006 16:20:46 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>
Subject: Note: Slides are background material for Greg's talk, won't be presented at IETF65
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>

Sorry to bother you again,

Please note that these slides are intended as background material for
D.3.2 (Design Guidelines, by Greg Weber); I won't present them myself.

Emile.

On Mon, Mar 20, 2006 at 04:02:54PM +0100, Emile van Bergen wrote:

> Please find my slides concerning the Extended Attribute format at
> http://www.xs4all.nl/~evbergen/e-advies-nl/ietf/ietf65_radext_extattr_evb_1.pdf

--
to unsubscribe send a message 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, 20 Mar 2006 15:03:21 +0000
Date: Mon, 20 Mar 2006 16:02:54 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], Bernard Aboba <[email-masked]>
Subject: Re: REMINDER: Submission of presentations (slides) for the RADEXT WG session at IETF-65
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>

Please find my slides concerning the Extended Attribute format at

http://www.xs4all.nl/~evbergen/e-advies-nl/ietf/ietf65_radext_extattr_evb_1.pdf

Kind regards,

Emile.

On Fri, Mar 17, 2006 at 05:55:36PM -0500, Nelson, David wrote:

> REMINDER:
>  
> > Please submit your RADEXT WG presentation materials to the chairs
> ASAP.
> > We would *really* like to have them all posted prior to the RADEXT
> session
> > on Tuesday morning of IETF week.
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 20 Mar 2006 13:53:10 +0000
Date: Mon, 20 Mar 2006 14:52:04 +0100
From: [email-masked]
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert \(Bert\)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure)

>>>
>>>"This counter may experience discontinuity when the Dynamic 
>>>Authorization Client (DAC) module is (re)started".
>>
>>Why only the DAC module?
> 
> 
> IMO, in theory, a DAC/DAS can be restarted regardless of the system
> restart(or sysUpTime). A similar statement is applicable to DAS
> Mib/module.
> 

Is it enough bu saying that there is a discontinuity at DAC or DAS 
module restart or is there then also a need for a scalar that contains 
the value of sysUpTime at the time the discontinuity happened? For 
implementations where the DAC or DAS cannot restart without that the 
whole system restarts, this will always contain zero. This looks better 
to me but then the case where counters survive a restart (e.g., if they 
are put in persistent memory) is not possible anymore. I am not really 
interested in that case since these counters are not so important that 
they have to survive a restart. Introducing such an object would also 
mean that when the management application restarts (sysUpTime is zero), 
then also the counters have to be reset even though the DAC or DAS 
module might not have restarted (which is no problem for me).

So, what is now the preference:

1) stating for each counter that it may experience a discontinuity when 
the DAC or DAS module (re)starts.
2) introducing such a scalar
3) use sysORUpTime instead

Thanks,
Stefaan

> Thanks
> Nagi.
> 
> 
>>/js
>>
>>-- 
>>Juergen Schoenwaelder		    International University Bremen
>><http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
>>28725 Bremen, Germany
> 
> 

--
to unsubscribe send a message 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, 20 Mar 2006 13:14:27 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Cc: [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/ser ver mibs structure)
Date: Mon, 20 Mar 2006 14:13:51 +0100

I think that would be OK, but where are the counters
kept to survive a restart?

Bert

> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:[email-masked]]
> Sent: Sunday, March 19, 2006 22:34
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: [email-masked]; Dan Romascanu (E-mail)
> Subject: MIB Counters discontinuity (Was RE: radius dynauth
> client/server mibs structure)
> 
> 
> Bert,
> 
> > Mmm... the "wraps from the max value to zero" is redundant, 
> > because that is the behaviour of every Counter32 and 
> > Counter64. That is already specified in RFC2578.
> > W.r.t "is reset upon system (re)initialization", that is not 
> > exactly waht we wanted either. I do not know what you mean 
> > with "reset".
> > It is not REQUIRED that counter reset to sero (if that is 
> > what you mean).
> > They MAY do so, butnot required.
> > I think what you want to write is:
> > 
> >    This counter will only experience a discuntinuity when the system
> >    (re)starts as indicated by the value of sysUpTime.
> > 
> 
> Do you think mentioning "may" in the sentence is appropriate.
> 
>  "This counter may experience a discontinuity when the system 
> (re)starts
> as indicated by the value of sysUpTime." 
> 
> 
> Thanks
> Nagi.
> 

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

Delivery-date: Mon, 20 Mar 2006 10:02:39 +0000
Content-class: urn:content-classes:message
Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure)
Date: Mon, 20 Mar 2006 15:31:49 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Dan Romascanu \(E-mail\)" <[email-masked]>

> > Juergen, Bert and all,
> >=20
> > We have two options then. Please let us know which one=20
> works for you.
> >=20
> > 1. As Juergen suggested "This counter uses sysUpTime as the=20
> > discontinuity indicator. Any discontinuity of this counter=20
> must cause a
> > reset of 	sysUpTime."
> >=20
> > 2. All we want to convey in the MIBs is that the counter might=20
> > experience discontinuity when the respective (DAC or DAS) module is=20
> > (re)started. Not sure if we need to draw any relation to=20
> sysUpTime or=20
> > some other object. Is implementing the sysUptime mandatory?
>=20
> An SNMP agent without sysUptime (the default discontinuity=20
> indicator for all counters) is kind of broken.

OK.

>=20
> > If not, does the below work?
> >=20
> > "This counter may experience discontinuity when the Dynamic=20
> > Authorization Client (DAC) module is (re)started".
>=20
> Why only the DAC module?

IMO, in theory, a DAC/DAS can be restarted regardless of the system
restart(or sysUpTime). A similar statement is applicable to DAS
Mib/module.

Thanks
Nagi.

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561,=20
> 28725 Bremen, Germany
>=20

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

Delivery-date: Mon, 20 Mar 2006 08:51:06 +0000
Date: Mon, 20 Mar 2006 09:50:46 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure)
Reply-To: [email-masked]
Mail-Followup-To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>

On Mon, Mar 20, 2006 at 02:06:16PM +0530, Nagi Reddy Jonnala (njonnala) wrote:
> Juergen, Bert and all,
> 
> We have two options then. Please let us know which one works for you.
> 
> 1. As Juergen suggested "This counter uses sysUpTime as the
> discontinuity indicator. Any discontinuity of this counter must cause a
> reset of 	sysUpTime."
> 
> 2. All we want to convey in the MIBs is that the counter might
> experience discontinuity when the respective (DAC or DAS) module is
> (re)started. Not sure if we need to draw any relation to sysUpTime or
> some other object. Is implementing the sysUptime mandatory? 

An SNMP agent without sysUptime (the default discontinuity indicator
for all counters) is kind of broken.

> If not, does the below work?
> 
> "This counter may experience discontinuity when the Dynamic
> Authorization Client (DAC) module is (re)started".

Why only the DAC module?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message 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, 20 Mar 2006 08:36:28 +0000
Content-class: urn:content-classes:message
Subject: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure)
Date: Mon, 20 Mar 2006 14:06:16 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Dan Romascanu \(E-mail\)" <[email-masked]>

Juergen, Bert and all,

We have two options then. Please let us know which one works for you.

1. As Juergen suggested "This counter uses sysUpTime as the
discontinuity indicator. Any discontinuity of this counter must cause a
reset of 	sysUpTime."

2. All we want to convey in the MIBs is that the counter might
experience discontinuity when the respective (DAC or DAS) module is
(re)started. Not sure if we need to draw any relation to sysUpTime or
some other object. Is implementing the sysUptime mandatory? If not, does
the below work?

"This counter may experience discontinuity when the Dynamic
Authorization Client (DAC) module is (re)started".

Thanks
Nagi

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]=20
> Sent: Monday, March 20, 2006 1:08 PM
> To: Nagi Reddy Jonnala (njonnala)
> Cc: [email-masked]; Wijnen, Bert (Bert);=20
> [email-masked]; Dan Romascanu (E-mail)
> Subject: Re: radius dynauth client/server mibs structure
>=20
> On Mon, Mar 20, 2006 at 10:26:32AM +0530, Nagi Reddy Jonnala=20
> (njonnala) wrote:
> =20
> > I believe sysUpTime is typically used to record the system uptime.
>=20
> No.
>=20
> > However the above definition seems to underscore that it=20
> records the=20
> > network management portion of the system and not=20
> necessarily the whole=20
> > system.  Agree?
>=20
> Yes, I believe the definition in RFC 3418 to be correct.
>=20
> > As I mentioned in the other thread, how about the below.
> >=20
> > "This counter *may* experience a discontinuity when the system=20
> > (re)starts as indicated by the value of sysUpTime."
>=20
> The system restart event is not really important (as it=20
> causes sysUpTime to be likely reset and managers will simply=20
> deal with it). The more interesting event is the restart of=20
> the subsystem that maintains the MIB counters, e.g., the=20
> restart of the RADIUS server itself.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561,=20
> 28725 Bremen, Germany
>=20

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

Delivery-date: Mon, 20 Mar 2006 07:38:41 +0000
Date: Mon, 20 Mar 2006 08:37:47 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: Re: radius dynauth client/server mibs structure
Reply-To: [email-masked]
Mail-Followup-To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>

On Mon, Mar 20, 2006 at 10:26:32AM +0530, Nagi Reddy Jonnala (njonnala) wrote:
 
> I believe sysUpTime is typically used to record the system uptime.

No.

> However the above definition seems to underscore that it records the
> network management portion of the system and not necessarily the whole
> system.  Agree?

Yes, I believe the definition in RFC 3418 to be correct.

> As I mentioned in the other thread, how about the below.
> 
> "This counter *may* experience a discontinuity when the system
> (re)starts as indicated by the value of sysUpTime." 

The system restart event is not really important (as it causes
sysUpTime to be likely reset and managers will simply deal with
it). The more interesting event is the restart of the subsystem that
maintains the MIB counters, e.g., the restart of the RADIUS server
itself.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message 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, 20 Mar 2006 04:57:12 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 20 Mar 2006 10:26:32 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>, "Dan Romascanu \(E-mail\)" <[email-masked]>

Juergen,

Please see inline.
 =20
> Are you sure? I see two problems with the sentence above:
>=20
> (a) sysUpTime does not record the system uptime; here is what RFC 3418
>     tells us:
>=20
>                "The time (in hundredths of a second) since the
>                network management portion of the system was last
>                re-initialized."

I believe sysUpTime is typically used to record the system uptime.
However the above definition seems to underscore that it records the
network management portion of the system and not necessarily the whole
system.  Agree?

As I mentioned in the other thread, how about the below.

"This counter *may* experience a discontinuity when the system
(re)starts as indicated by the value of sysUpTime."=20

>=20
> (b) are you really sure counters will not have a discontinuity if a
>     RADIUS server is restarted? Counters which live in a Radius server
>     (e.g. an embedded AgentX client) most likely won't be=20
> persistent...

It may not be the case (at least for the NASes) with the distribution
model.=20

Thanks
Nagi.

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

Delivery-date: Mon, 20 Mar 2006 04:35:04 +0000
Content-class: urn:content-classes:message
Subject: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure)
Date: Mon, 20 Mar 2006 10:03:57 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Dan Romascanu \(E-mail\)" <[email-masked]>

Bert,

> Mmm... the "wraps from the max value to zero" is redundant,=20
> because that is the behaviour of every Counter32 and=20
> Counter64. That is already specified in RFC2578.
> W.r.t "is reset upon system (re)initialization", that is not=20
> exactly waht we wanted either. I do not know what you mean=20
> with "reset".
> It is not REQUIRED that counter reset to sero (if that is=20
> what you mean).
> They MAY do so, butnot required.
> I think what you want to write is:
>=20
>    This counter will only experience a discuntinuity when the system
>    (re)starts as indicated by the value of sysUpTime.
>=20

Do you think mentioning "may" in the sentence is appropriate.

 "This counter may experience a discontinuity when the system (re)starts
as indicated by the value of sysUpTime."=20

Thanks
Nagi.

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

Delivery-date: Sun, 19 Mar 2006 21:49:49 +0000
Date: Sun, 19 Mar 2006 22:49:25 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: Re: radius dynauth client/server mibs structure
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>

On Sun, Mar 19, 2006 at 10:18:07PM +0100, [email-masked] wrote:

> >I think what you want to write is:
> >
> >   This counter will only experience a discuntinuity when the system
> >   (re)starts as indicated by the value of sysUpTime.
> 
> Ok, I got the point. we will use this sentence and correct it for both docs.

Are you sure? I see two problems with the sentence above:

(a) sysUpTime does not record the system uptime; here is what RFC 3418
    tells us:

               "The time (in hundredths of a second) since the
               network management portion of the system was last
               re-initialized."

(b) are you really sure counters will not have a discontinuity if a
    RADIUS server is restarted? Counters which live in a Radius server
    (e.g. an embedded AgentX client) most likely won't be persistent...

Perhaps you really want to state that the counters use sysUpTime as
the discontinuity indicator and that any discontinuities the counters
may experience causes a reset of sysUpTime (if you really want this
behavior):

	This counter uses sysUpTime as the discontinuity indicator.
	Any discontinuity of this counter must cause a reset of
	sysUpTime.

Another option could be to use the relevant sysORUpTime object as the
discontinuity indicator but then this would require proper
implementation of the sysORTable and stupid managers will rely on the
default sysUpTime anyway (if they check for discontinuities at all).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message 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, 19 Mar 2006 21:18:54 +0000
Date: Sun, 19 Mar 2006 22:18:07 +0100
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: Re: radius dynauth client/server mibs structure

Hi Bert,

Thanks for these comments. We will limit the Address type to IPv4 and IPv6.

see more below

Wijnen, Bert (Bert) wrote:

> I checked both new documents.
> 
> You may want to check on page 7/8:
>                Copyright (C) The Internet Society (2006).  Initial
>                version as published in RFC yyyy;
>                for full legal notices see the RFC its"
>    -- RFC Ed.: replace yyyy with actual RFC number & remove this note
> 
> So I huess this sentence is incomplete: see the RFC its ???
> Probably should be: see the RFC itself.
> 

yes something went worng here with the last update of the draft and a 
part of the sentence disappeared.

> 
>>- add sentence "This counter wraps from the maximum value to 
>>zero and is
>>reset upon system (re)initialization." for all counters of type
>>Counter32
> 
> 
> Mmm... the "wraps from the max value to zero" is redundant, because
> that is the behaviour of every Counter32 and Counter64. That is
> already specified in RFC2578.
> W.r.t "is reset upon system (re)initialization", that is not exactly
> waht we wanted either. I do not know what you mean with "reset".
> It is not REQUIRED that counter reset to sero (if that is what you mean).
> They MAY do so, butnot required.
> I think what you want to write is:
> 
>    This counter will only experience a discuntinuity when the system
>    (re)starts as indicated by the value of sysUpTime.
> 
> 

Ok, I got the point. we will use this sentence and correct it for both docs.

Currently version 04 is already submitted, so we  will make it version 05.

Thanks,
Stefaan

> 
>>- remove ref to IANA copyright.
> 
> 
> thanks
> 
> 
>>- some minor formatting (line breaks in the mib)
>>
> 
> 
> OK
> 
> My comments to the other 4 mib docs (2618bis etc) also apply for 
> your use of InetAddress and InetAddressType. I know I did say (in my point 3)
> last time that this was acceptable for Informational RFC. But now that I
> reviewed the other MIB modules and now that I am asking for the below
> updates tyo those, it would be best to do so too for these 2
> modules, in order to be consistent for all RADIUS related MIB modules.
> So pls translate the following to your own objects and consider to
> make similar changes:
> 
> -  radiusAuthServerInetAddress OBJECT-TYPE
>          SYNTAX     InetAddress
>          MAX-ACCESS read-only
>          STATUS     current
>          DESCRIPTION
>                "The IP address of the RADIUS authentication
>                 server referred to in this table entry, using
>                 the version neutral IP address format."
>          ::= { radiusAuthServerExtEntry 3 }
> 
>    according to RFC4001, you MUST specify which object of SYNTAX 
>    InetAddressType controls the format of this object. I t is clear 
>    which one  it is, b ut it would be good to add that.
> 
> - radiusAuthClientServerInetPortNumber
>   According to RFC4001, you must specify what the value zero means 
>   for this object.
> 
> - for this one
>    radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
>         STATUS  current
>         DESCRIPTION
>               "The compliance statement for authentication
>                clients implementing the RADIUS Authentication
>                Client IPv6 Extensions MIB.  Implementation of
>                this module is for entities that support IPv6,
>                or support IPv4 and IPv6."
>         MODULE  -- this module
>                MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }
> 
>         ::= { radiusAuthClientMIBCompliances 2 }
>  
>   I think it would be better to do:
> 
>    radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
>         STATUS  current
>         DESCRIPTION
>               "The compliance statement for authentication
>                clients implementing the RADIUS Authentication
>                Client IPv6 Extensions MIB.  Implementation of
>                this module is for entities that support IPv6,
>                or support IPv4 and IPv6."
>         MODULE  -- this module
>                MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }
> 
>         OBJECT     radiusAuthServerInetAddressType
>         SYNTAX     InetAddressType { ipv4(1), ipv6(2) }
>         DESCRIPTION
>            "An implementation is only required to support IPv4 and
>             globally unique IPv6 addresses."
> 
>         OBJECT     radiusAuthServerInetAddress
>         SYNTAX     InetAddress (SIZE(4|16)) 
>         DESCRIPTION
>            "An implementation is only required to support IPv4 and
>             globally unique IPv6 addresses."
> 
> Bert
> 
>>I tried a diff but that output is rather messy, so I sent you the 
>>complete drafts.
>>
>>Thanks,
>>Stefaan
>>
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message 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, 19 Mar 2006 05:45:14 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Review of RADIUS Digest-07 Document
Date: Sun, 19 Mar 2006 06:43:53 +0100

[when responding, it is probably best to only copy the radiusext
 WG list and not the AAA WG list.]

Do the new rev is available, in fact has been since Mar 8th.

Do we have consensus that this is now OK and that we can check
if security ADs are also happy, and as a result we can then 
also finish the draft-ietf-aaa-diameter-sip-app-xx.txt document?

It would be really great if we can finalize (i.e. get acceptable
I-Ds posted) by Wed at the latest, so we can try and clear these
2 documents for approval.

Pleas keep in mind my response to the updated version:
  > Wolfgang wrote:
  > my main focus for the -07 version was to address the 'discuss'
  > points from the IESG site.
  >  
  In fact, since the document was (and basically still is) in IESG evaluation,
  I think the WG should not add new issues/concerns unless there is a FATAL
  FLAW that we discovered late. 

  Bert (speaking as one of the ADs).

Bert

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Bernard Aboba
> Sent: Tuesday, March 07, 2006 17:04
> To: [email-masked]
> Subject: [AAA-WG]: Review of RADIUS Digest-07 Document
> 
> 
> A new version of the RADIUS Digest document has been 
> submitted in response 
> to IETF last call and IESG DISCUSS comments. Until the 
> specification ends 
> up on the archive, it is available here: 
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-
> auth-07.txt
> 
> When it ends up on the archive, it will be available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-a
> uth-07.txt
> 
> Please examine this new version of the document to see whether it 
> addresses the open issues, which were filed on the RADEXT WG 
> issues list: 
> http://www.drizzle.com/~aboba/RADEXT/
> 
> These include the following:
> 
> Issue #             Title                              Owner
> 
> ---------- ------------------------- ---------------------- 
> 150           IANA Considerations          John Loughney
> 151           Another review               Kurt Zeilenga
> 152           Review                       Alexey Melnikov
> 159           Negotiation                  Wolfgang Beck
> 162           Nonce Replay Issue           Wolfgang Beck
> 173           Client Nonce Generation      Sam Hartman
> 174           Review                       Russ Housley
> 175           Some NITs                    Bert Wijnen
> 
> In particular, the following questions should have been addressed:
> 
> * Handling of client/server nonce generation (comments from 
> Sam Hartman, 
>   Glen Zorn and others) 
> * Extensibility for new algorithms (Russ Housley)
> * Editorial comments (many)
> 
> 
> 

--
to unsubscribe send a message 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, 19 Mar 2006 05:45:06 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: "Dan Romascanu (E-mail)" <[email-masked]>, "David Kessens (E-mail)" <[email-masked]>
Subject: AD review of rfc2618bis-02 through rfc2621bis-02
Date: Sun, 19 Mar 2006 06:43:58 +0100

Editor and WG,

Dan had already done MIB doctor review and he is basically OK
I believe). So I did a quick check in my role as AD.

  draft-ietf-radext-rfc2618bis-02.txt 
  draft-ietf-radext-rfc2619bis-02.txt 
  draft-ietf-radext-rfc2620bis-02.txt 
  draft-ietf-radext-rfc2621bis-02.txt 

I did just do draft-ietf-radext-rfc2618bis-02.txt
The others probably have similar minor issues.

As far as I am concerned, we can do IETF Last Call (these go
for standards track so we must do IETF LC) now. You can then
consider below comments as the first set of IETF LC comments.
And then address them right after IETF Last Call, or maybe you 
want to wait and see if there are any IESG comments that you
could address at the same time. By that time, Dan will tell
you how to proceed.

Bert
---- comments
somewhat MUST change comments (easy, and basically admin
bureaucracy, but would be good to change):

  We do want a copyright statement in the DESCRIPTION clause of a module
  identity. So change
  OLD:
          DESCRIPTION
                "The MIB module for entities implementing the client
                 side of the Remote Authentication Dial-In User Service
                 (RADIUS) authentication protocol."
  NEW:
          DESCRIPTION
                "The MIB module for entities implementing the client
                 side of the Remote Authentication Dial-In User Service
                 (RADIUS) authentication protocol.
                 Copyright (C) The Internet Society (2006).  This version
                 of this MIB module is part of RFC xxxx; see the RFC
                 itself for full legal notices."
           -- RFC Ed.: replace xxxx with actual RFC number & remove this note

-  radiusAuthServerInetAddress OBJECT-TYPE
         SYNTAX     InetAddress
         MAX-ACCESS read-only
         STATUS     current
         DESCRIPTION
               "The IP address of the RADIUS authentication
                server referred to in this table entry, using
                the version neutral IP address format."
         ::= { radiusAuthServerExtEntry 3 }

   according to RFC4001, you MUST specify which object of SYNTAX 
   InetAddressType controls the format of this object. I t is clear 
   which one  it is, b ut it would be good to add that.

- radiusAuthClientServerInetPortNumber
  According to RFC4001, you must specify what the value zero means 
  for this object.

- for this one
   radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
               clients implementing the RADIUS Authentication
               Client IPv6 Extensions MIB.  Implementation of
               this module is for entities that support IPv6,
               or support IPv4 and IPv6."
        MODULE  -- this module
               MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        ::= { radiusAuthClientMIBCompliances 2 }
 
  I think it would be better to do:

   radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
               clients implementing the RADIUS Authentication
               Client IPv6 Extensions MIB.  Implementation of
               this module is for entities that support IPv6,
               or support IPv4 and IPv6."
        MODULE  -- this module
               MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        OBJECT     radiusAuthServerInetAddressType
        SYNTAX     InetAddressType { ipv4(1), ipv6(2) }
        DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

        OBJECT     radiusAuthServerInetAddress
        SYNTAX     InetAddress (SIZE(4|16)) 
        DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

- real nits and admin stuff

  !! Contains embedded space:
  P004 L021:    textual conventions defined in this memo [RFC 4001] that support all

  !! Missing citation for Normative reference:
  P020 L018:    [RFC2574]  Blumenthal, U. and B. Wijnen, "User-based Security Model

  !! Missing citation for Normative reference:
  P020 L022:    [RFC2575]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based

  !! Missing citation for Normative reference:
  P020 L049:    [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An

  !! Missing citation for Normative reference:
  P021 L006:    [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the

  RFC2574 and RFC2575 should be replaced by RFC3414 and RFC3415

  RFC3410 is better listed as an Informative reference.

  In general, pls re-check all citations/references.

--
to unsubscribe send a message 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, 19 Mar 2006 05:44:58 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Dan Romascanu (E-mail)" <[email-masked]>
Subject: RE: radius dynauth client/server mibs structure
Date: Sun, 19 Mar 2006 06:43:59 +0100

I checked both new documents.

You may want to check on page 7/8:
               Copyright (C) The Internet Society (2006).  Initial
               version as published in RFC yyyy;
               for full legal notices see the RFC its"
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

So I huess this sentence is incomplete: see the RFC its ???
Probably should be: see the RFC itself.

More below.

I propose to make the changes as suggested here and then submit to ID-repository.
I believe it opens up again on Monday during IETF65.

See further inline:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, March 13, 2006 22:05
> To: Nelson, David; Wijnen, Bert (Bert)
> Cc: Nagi Reddy Jonnala (njonnala); [email-masked];
> [email-masked]
> Subject: Re: radius dynauth client/server mibs structure
> 
> 
> 
> Hi Bert, Dave,
> 
> The updated versions are attached.
> 
> Changes are:
> - change 2005 into 2006 in DESCRIPTION of MIB

good, but see above

> - group the scalars according the comment of Juergen

Looks good to me now

> - add sentence "This counter wraps from the maximum value to 
> zero and is
> reset upon system (re)initialization." for all counters of type
> Counter32

Mmm... the "wraps from the max value to zero" is redundant, because
that is the behaviour of every Counter32 and Counter64. That is
already specified in RFC2578.
W.r.t "is reset upon system (re)initialization", that is not exactly
waht we wanted either. I do not know what you mean with "reset".
It is not REQUIRED that counter reset to sero (if that is what you mean).
They MAY do so, butnot required.
I think what you want to write is:

   This counter will only experience a discuntinuity when the system
   (re)starts as indicated by the value of sysUpTime.

> - remove ref to IANA copyright.

thanks

> - some minor formatting (line breaks in the mib)
> 

OK

My comments to the other 4 mib docs (2618bis etc) also apply for 
your use of InetAddress and InetAddressType. I know I did say (in my point 3)
last time that this was acceptable for Informational RFC. But now that I
reviewed the other MIB modules and now that I am asking for the below
updates tyo those, it would be best to do so too for these 2
modules, in order to be consistent for all RADIUS related MIB modules.
So pls translate the following to your own objects and consider to
make similar changes:

-  radiusAuthServerInetAddress OBJECT-TYPE
         SYNTAX     InetAddress
         MAX-ACCESS read-only
         STATUS     current
         DESCRIPTION
               "The IP address of the RADIUS authentication
                server referred to in this table entry, using
                the version neutral IP address format."
         ::= { radiusAuthServerExtEntry 3 }

   according to RFC4001, you MUST specify which object of SYNTAX 
   InetAddressType controls the format of this object. I t is clear 
   which one  it is, b ut it would be good to add that.

- radiusAuthClientServerInetPortNumber
  According to RFC4001, you must specify what the value zero means 
  for this object.

- for this one
   radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
               clients implementing the RADIUS Authentication
               Client IPv6 Extensions MIB.  Implementation of
               this module is for entities that support IPv6,
               or support IPv4 and IPv6."
        MODULE  -- this module
               MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        ::= { radiusAuthClientMIBCompliances 2 }
 
  I think it would be better to do:

   radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
              "The compliance statement for authentication
               clients implementing the RADIUS Authentication
               Client IPv6 Extensions MIB.  Implementation of
               this module is for entities that support IPv6,
               or support IPv4 and IPv6."
        MODULE  -- this module
               MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }

        OBJECT     radiusAuthServerInetAddressType
        SYNTAX     InetAddressType { ipv4(1), ipv6(2) }
        DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

        OBJECT     radiusAuthServerInetAddress
        SYNTAX     InetAddress (SIZE(4|16)) 
        DESCRIPTION
           "An implementation is only required to support IPv4 and
            globally unique IPv6 addresses."

Bert
> I tried a diff but that output is rather messy, so I sent you the 
> complete drafts.
> 
> Thanks,
> Stefaan
> 

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

Delivery-date: Fri, 17 Mar 2006 22:56:13 +0000
Content-class: urn:content-classes:message
Subject: REMINDER: Submission of presentations (slides) for the RADEXT WG  session at IETF-65
Date: Fri, 17 Mar 2006 17:55:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>

REMINDER:
=20
> Please submit your RADEXT WG presentation materials to the chairs
ASAP.
> We would *really* like to have them all posted prior to the RADEXT
session
> on Tuesday morning of IETF week.

--
to unsubscribe send a message 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, 17 Mar 2006 17:10:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Fri, 17 Mar 2006 12:09:10 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

=20
Now the VLAN-01 strawman says:
      The VLAN Flag field is one octet in length,=20
      and indicates whether the frames on the VLAN=20
      are tagged (0x31) or untagged (0x32).=20

But it doesn't say *how* the flag field indicates=20
tagged vs. untagged.  With the attribute name being
VLAN Flag, I would think that attribute's values
would be 1 or 0.  Do I indicate 'tagged' by setting
the value of VLAN Flag to 1 or to 0x31?

Greg

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, March 16, 2006 1:15 PM
> To: [email-masked]
> Subject: Proposed Resolution to Issue 180: Misuse of Data Types
>=20
> The text of Issue 180 (and some of the subsequent discussion)=20
> is enclosed=20
> below.
>=20
> The proposed resolution is to change "VLAN Tag" to "VLAN=20
> Flag" everywhere in=20
> the document.
>=20
> In looking at the mailing list discussion, I did not detect=20
> consensus for=20
> making other changes.
>=20
> --------------------------------------------------------------
> --------------------------------------
> Issue 180: Misuse of Data Types
> Submitter name: Dave Nelson
> Submitter email address: [email-masked]
> Date first submitted: March 14, 2006
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html
> Document: VLAN/Priority -00
> Comment type: 'T'echnical
> Priority: '1' Should fix
> Section: 2.1.  Egress-VLANID
> Rationale/Explanation of issue:
>=20
> I had previously raised this issue, and the resolution was we=20
> could use a=20
> RADIUS data
> type of Integer, because only the VLANID (12-bit) portion=20
> would be used.=20
> Thus, this object could be thought  of as a range-limited=20
> integer. Since I=20
> see that we still have the VLAN Tag fields, that resolution=20
> falls apart.  I=20
> claim that this data object is not an Integer.
>=20
> Someone offered the suggestion that Integers are not simply=20
> the mathematical=20
> definition, i.e. the positive  and negative whole numbers and=20
> zero, that we=20
> all learned in high school. With all due respect,
>=20
> I think that's patently wrong. It is true that one can write=20
> programs that=20
> treat 8-bit, 16-bit,
> 32-bit or 64-bit "integers" as packed data structures using=20
> mask, bit-field,=20
> shift and rotate operations.
>=20
> I still claim that those data structures are *not* integers=20
> simply because=20
> they can be packed within
> the computer memory storage that is also used by integers.=20
> Hopefully, there=20
> is more to data modeling  than the storage length in bits. :-)
>=20
> We are currently having a debate on the RADEXT WG list about=20
> the issue of=20
> derived data types, and no  consensus has yet been reached.=20
> However, until=20
> such a consensus is reached, it seems most appropriate  to follow the=20
> existing practice of defining derived data types as Strings, with the=20
> bit-fields described in the text. I think that over-loading=20
> base RADIUS data=20
> types with new meanings is inappropriate.
>=20
> Given the relative timing of WGLC on this draft and the=20
> emerging consensus=20
> on RADIUS Attribute Design Guidelines, I think this is the=20
> best compromise.
>=20
> Requested change:
>=20
> OLD:
>=20
> Integer
>=20
> The Integer field is four octets in length. The format is
> described below:
>=20
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | VLAN Tag      |      Pad              |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> The VLAN Tag field is one octet in length, and indicates whether
> the frames on the VLAN are tagged (0x31) or untagged (0x32). The
> Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
> 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.
>=20
> NEW:
>=20
> String
>=20
> The String field is four octets in length. The format is
> described below:
>=20
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | VLAN Tag      |      Pad              |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> The VLAN Tag field is one octet in length, and indicates whether
> the frames on the VLAN are tagged (0x31) or untagged (0x32). The
> Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
> 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.
>=20
> Section: 2.3. Egress-VLAN-Name
> Rationale/Explanation of issue:
>=20
> I'm rather uncomfortable with the usage of the VLAN Tag=20
> field, as it seems=20
> to be at variance
> with the emerging WG consensus on complex or structured data=20
> types. Once we=20
> standardize
> this usage, there will be one more precedent in a RADIUS RFC=20
> to support=20
> ad-hoc data typing.
> If that's what RADEXT ultimately recommends, then this will=20
> be fine. If the=20
> recommendation
> is to use a more formal method of aggregating structured=20
> data, this will be=20
> one more anomaly.
>=20
> VLAN Tag
>=20
> The VLAN tag field is one octet in length, and indicates whether
> the frames on the VLAN are tagged (0x31) or untagged (0x32).
>=20
> Requested change:
>=20
> I have no idea what (if any change) to request. Chalk this=20
> comment up as my=20
> personal lament
> over the process that RADEXT has followed -- delaying consensus on=20
> attributes design to the
> point where we are standardizing new attributes using complex=20
> data types=20
> prior to having
> defined the design guidelines for complex data types.
>=20
> Section 2.4 User-Priority-Table
> Rationale/Explanation of issue:
>=20
> With all due deference to the well understood "array - string=20
> duality" we=20
> find in programming
> languages such as C, I think that expressing a attribute=20
> whose value is an=20
> array in the form of
> a RADIUS String type is unfortunate, for the reasons expressed above.
>=20
> Requested change:
>=20
> (See above.)
>=20
> The only way that I see to actually resolve my data typing /=20
> data modeling=20
> concerns is to delay
> sending any RADEXT work item that uses derived data types to=20
> the IESG until=20
> after we have sent
> the RADIUS Design Guidelines and RADIUS Extended Attributes=20
> I-Ds to the=20
> IESG, and that approach
> is not compatible with our milestones.
>=20
> [Glen Zorn]
> With all due respect, I think that you are the one doing the=20
> overloading:=20
> RFC 2568 says
>=20
> 	integer   32 bit unsigned value, most significant octet first.
>=20
> That's it.  No range, no interpretation, nothing else.
>=20
> [Emile Van Bergen]
> >I see nothing that indicates this data type is anything other than an
> >integer, typically expressed in a C language declaration as "unsigned
> >long".
>=20
> You're completely correct. And in the case of the VLAN attribute, it
> *does* contain an unsigned integer value, one that's=20
> calculated as follows:
>=20
> value =3D vlanflag * 16777216 + vlanid
>=20
> The reverse goes as follows:
>=20
> vlanflag =3D value / 16777216
> vlanid =3D value % 16777216
>=20
> (where
> * denotes unsigned integer multiplication,
> + denotes unsigned integer addition,
> / denotes unsigned integer division and
> % denotes taking the reminder of an unsigned integer division,
> all to be carried out on unsigned integers in the range 0 .. 2**32-1)
>=20
> I'm not believing that people on this list would have to be explained
> that shifting and masking bits are *not* magic operations that you can
> only perform if you program in assembly (or its portable flavour, C),
> but that those are normal mathematical operations on normal integers:
> multiply and take remainder (by powers of 2).
>=20
> You can do that, I think, even in Java, SAP/r3, XSLT, SQL and=20
> whatever.
> This whole issue has nothing whatsoever to do with C structures.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Fri, 17 Mar 2006 02:59:32 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 22:01:14 -0500
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>
Cc: "Barney Wolff" <[email-masked]>, "Alan DeKok" <[email-masked]>, <[email-masked]>

Emile,=20

> This WGs very existence, how reluctantly it was started, is=20
> testament that people rather build upon RADIUS than look at=20
> DIAMETER for their solutions.

I am sorry you don't get it!!!=20

It's not that we rather build upon RADIUS.  We live in a commercial
world that requires us to build upon RADIUS.  We are not given a choice.
We have paying customers who invested millions of dollars each in their
RADIUS infrastructure and they don't want it to go away (yet).

> I find it then entirely foolish to suggest that a blanket=20
> transport mechanism for DIAMETER inside RADIUS would solve=20
> all our issues.=20

Given the evidence I have seen, the Diameter encoding will work.

Take away the 'M' and 'P' bits because I don't think those make sense
much.

Any shortcomings should be addressable -- unless of course the IETF
decides to get in the way as they do with RADIUS.

> I find it incomprehensible that the DIAMETER format would not=20
> need any evaluation against the alternatives on the merits,=20
> but that people can just wave their hands and say, there's=20
> already some diameter parsing code in many RADIUS server's=20
> that support TTLS in some form or other, so hey, 'tis the=20
> only sensible road ahead.

If you want to transition from RADIUS to Diameter why not get the
attributes aligned -- it will make the cut over a lot easier.

=20
> Really, is that all we can muster these days?

I havent seen any better approach so I guess -- yes.

I am sorry that makes you sad.

> Cheers,
>=20
>=20
> Emile.
>=20
> --=20
> E-Advies - Emile van Bergen           [email-masked]     =20
> tel. +31 (0)78 6136282           http://www.e-advies.nl   =20
>=20

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

Delivery-date: Thu, 16 Mar 2006 23:51:11 +0000
Date: Fri, 17 Mar 2006 00:51:07 +0100
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Thu, Mar 16, 2006 at 06:06:33PM -0500, Alan DeKok wrote:

> Emile van Bergen <[email-masked]> wrote:
> > I find it incomprehensible that the DIAMETER format would not need any
> > evaluation against the alternatives on the merits, but that people can
> > just wave their hands and say, there's already some diameter parsing
> > code in many RADIUS server's that support TTLS in some form or other, so
> > hey, 'tis the only sensible road ahead.
> 
>   s/only/proven working, implemented, deployed, and functional/
> 
>   If there are other alternatives, they should be explored, of course.
> But the diameter format, while wasteful of space in the RADIUS packet,
> *is* a proven one.

It's proven as a working AAA protocol. It's not yet proven as the
successor to RADIUS. It's not proven as the best way to fix urgent
RADIUS issues ad interim, as our charter sets out to do, before people
move to DIAMETER.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 16 Mar 2006 23:48:37 +0000
Date: Fri, 17 Mar 2006 00:48:05 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Wed, Mar 15, 2006 at 11:17:31AM -0500, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > We're having a theoretical debate, and you're not answering the
> > question. Let me try again. If RFC 2865 didn't have a time base type,
> > how would you propose a session time to be conveyed? As an attribute
> > consisting of subattributes allocated from a global IANA Type number
> > space, however wide?
> 
> OK, theoretically speaking then.
> 
> If there were no RADIUS time data type, then I would search to see if
> there were a standard one in common use, preferably one with a stable
> reference, e.g. an RFC.  I would almost certainly choose Unix Epoch time
> (seconds since January 1, 1970) which conveniently fits in an Integer.
> If I were worried about the 2024 (or whenever) wrap-around, I'd find
> another standard representation, and use that (maybe an unsigned long
> long, i.e. 64-bit integer).  If I were *forced* to use the
> representation you suggest, i.e. separate members of a structure for
> each of the "units" of time, and there were no existing standard I could
> reference, then I would look to the RADIUS Design Guidelines to see what
> is recommended.

Ok. So if I understand you correctly, you would suggest the current
criteria?

1. does a widely accepted standard type for the information exist? If so, 
   any packing used in that is OK.

2. if not, and you're not *forced* to use separate members either, then
   ... (you did not address that situation).

3. if you're *forced* to use separate members, you'd look at the Design
   Guidelines to see eg. how you would use the facilities provided by the 
   Extended Attribute.

> So, I haven't answered your question yet (but I will).  My point up to
> this juncture is that the WG should reach a consensus on design
> guidelines, and then each individual attribute design decision should be
> made with the benefit of those recommendations, providing a certain
> level of consistency.  This shouldn't be such an ad-hoc process, IMHO.
> I suppose this is a controversial opinion, something like advocating
> coding style standards.  :-)  While I have an opinion on this, I really
> don't care so much as to what the WG decides, as long as it comes to a
> consensus, and does so fairly quickly.  

Agreed, without sacrificing correctness to speed; RADIUS in particular
shows that good formats tend to stay around for a long time, sometimes
even long after aspects of the originally intended applications and
corresponding use style have moved on.

> I would prefer that the guidelines are substantive, and provide some
> real guidance, rather than simply codifying the existing ad-hoc
> practices.

Agreed, however, if you want to get any kind of traction with
implementors, it should not be prohibitively hard, nor require a
complete redesign in a completely different paradigma, to migrate from
those practices to the new recommendations.

There is a reason DIAMETER hasn't received the attention people expected
it to get. There is also a reason it was agreed that there would be a
RADEXT WG. Its very existence is a testament that DIAMETER adoption
isn't going as well as intended, that vendors so far prefer RADIUS (and
I would venture to say, not just due to networking (in the economic
sense) effects), and that there are some problems in RADIUS that people
want fixed, and fixed in RADIUS' way, not by RADIUS starting to
transport DIAMETER.

[snip]

> How would I suggest that the design guidelines be worded to recommend
> encoding of structured data representations?  My suggestion would be to
> use the Extended RADIUS Attribute (however it is ultimately defined) and
> use whatever grouping (data aggregation) method it supports to structure
> the member elements into a logical structure.  This could be via
> sub-attributes, or via tagged attributes, or via grouped attributes (as
> in Diameter).

Well, I agree, but as said in our conference call, I don't think that
the current design guidelines draft should remain leading after the
Extended Attribute specification is done.

I view that document as a survey of issues and a proposed set of
requirements for the Extended Attribute format and an accompanying
usage recommendations document, if any.

The only section that comes up with guidelines is section 7, and that's
rather brief in comparison with the rest. I would also suggest that some
of those criteria depend on what the Extended Attribute format will be.

I think that the the next step is to specify the Extended Attribute
format, as one that should be flexible enough to be able to absorb
existing RADIUS practice, as well as providing a common solution for the
largest current problems: limited standard attribute number space and
size and incompatible internal VSA formats.

The most common cases of vendors not used the RADIUS attribute format
inside their VSAs are those that use wider attribute number fields and
multiple subattributes inside one VSA.

So if we address that, then together with tagging and structures, we
have most things covered, and encourages vendors to use the
Extended-Attribute to encapsulate all their attributes in a common
format (the Extended Attribute format), instead using the
Vendor-Specific attribute to encapsulate one or more of their attributes
in a vendor specific manner.

Client vendors worried about server support needn't worry, because a
server that does not support the Extended Attribute won't support their
specific internal VSA structure either, unless they use RFC 2865's
suggested format for values the Vendor-Specific attribute.
with vendor specific code, allow 

That way, dictionary based implementations can gain access to more
attributes, without either requiring vendor specific code or
dictionaries that define lots of encoding parameters.

The last step is to provide guidance on which features of the format to
use in which cases, including what data types new attributes should use,
to encourage sane practice and also to cater for a smooth migration to
DIAMETER later. This would be a much expanded version of Section 7 of
the current Design Guidelines.

The reason to do it in two layers is that structure evolves at a much
slower pace than style. We still use the same protocol structure and
packet structure as 9 years ago, but usage style has *much* evolved. And
the structure is so popular that we're still using it.

So, following the charter, I think the extended attributes (and I hope
we'll have one draft to consider for adoption as a WG item, not two),
should use a format (inside a space created by concatenated RADIUS
attributes), that:

a. is able to absorb existing practice (eg. in terms of most of the
   Informational RFCs we have on RADIUS) without paradigm shifts or
   other nontrivial transformations (ie. no wholesale encapsulation
   of the DIAMETER protocol in a way as done for EAP)

b. addresses at least 90% of the reasons vendors didn't use the standard
   RADIUS format inside their VSAs (larger Type field, longer
   attributes), removing the need for packet parsers to contain vendor
   specific code or the need for parsers to be supplied with much
   knowledge from the dictionary;

c. encourages harmonization by creating large common attribute number 
   spaces, governed by shared policies instead of the current situation
   where you either need standards action or rely on another vendor's
   private assignment policy. Also note that our charter specifically adds
   the SDO-specific attribute class to the IETF and Vendor specific
   classes of attributes;

d. paves the way for a smooth migration to DIAMETER by allowing DIAMETER
   code points to be used and by strongly recommending the use of the
   DIAMETER data types for all basic scalar types. 

   (In practice, that doesn't narrow things down much; *everything* at
   the level we're working at uses 2's complement big-endian values with
   sizes of either 1, 2, 4, 8 octets, or a variable length octet string
   that's either not interpreted at all or interpreted as UTF-8).

> I think it's important to reiterate some thoughts expressed elsewhere in
> this general discussion, however.  One of those concepts is the issue of
> whether or not a RADIUS Server or RADIUS Client needs to take an action
> that depends on the value of one or more individual members of a data
> structure.  So far, much of this discussion has been from the view point
> of RADIUS Servers, in terms of data dictionary implementations.  We
> should also consider this from the NAS developer's viewpoint.

Agreed, but there the situation is often much easier, because NASes
already have specific code to implement the actual services that are
controlled by the RADIUS attributes that apply to them.

Therefore, service specific value encodings seem much less of a problem
for NAS vendors, and I think that's also the reason that we see so many
today.

> If a RADIUS entity (Server or Client) needs to take some action
> dependent upon an element in a structure, it would be valuable and
> desirable to have the individual elements easily addressable.  
>
> Having sub-attribute IDs for these is one way, and in an Extended
> RADIUS Attribute we can define this scheme without incurring any
> backwards compatibility penalties.  

That was exactly the point in my suggested format. It allows all
elements to be addressed 1. as a flat list of attributes, 2. as a flat
list of tagged attributes, 3. as an ordered list of attribute sets (by
splitting in sets based on tags), and 4. as an arbitrarily nested tree
of attributes.

Which addressing style depends on what the entity wants to do with the
attribute and the attribute's semantics when it occurs at one particular
level in the tree as opposed to another.

> We could also write custom string parser code for each individual
> attribute, which could work from fixed octet offsets, or could search
> for specified delimiter values in variable length fields.  I
> personally find this kind of code more cumbersome, less flexible, less
> re-usable, and more error prone.  It's certainly good job security for
> RADIUS developers.  :-)

I wholeheartedly agree with your point there. 

I personally even so thorougly hated that approach that I spent the
effort of making the OpenRADIUS dictionary able to deal with almost all
non-delimited formats, both fixed offsets and length field based, and
the policy language to easily allow splitting on delimiters.

However, after moving the format variation out of the code, the
complexity is in the dictionary, so I'd still rather see a more
harmonized approach to TLV formats. But for that to be successful, it
needs to be flexible and not requiring the adoption of a different
style, as DIAMETER does.

> If no RADIUS entity needs to take action on the values of the structure
> elements, e.g. it is passed to another entity (such as EAP), or it is
> simply intended to be dumped verbatim into a RADIUS Accounting Server
> log file, then it can perfectly well be densely packed into a string.
> My only concern with this approach is that the author of a new attribute
> *claims* that it can be treated as a string, because it's never parsed,
> when in fact implementations of that application eventually *do* need to
> have access to the individual data elements, and thus end up parsing
> densely packed strings.

Agreed.

> Another way to look at this issue, purely for the sake of analysis, is
> to see how the same data items would be encoded in ASN.1, using SMIv2,
> for a MIB.  Pretend that we're using SNMP to provision the NAS instead
> of RADIUS.  How would you write the MIB?  You could easily see a
> relationship between leaf OIDs and RADIUS attributes (or
> sub-attributes).  Now before anyone starts the flames, I realize that
> RADIUS is not like SNMP.  For one thing RADIUS doesn't have a formal
> data model, like SNMP.  I think the exercise is potentially instructive,
> none the less.

SNMP, including traps and writes (RFC 1067) predates RADIUS (RFC 2058)
by 9 years (1988 vs. 1997).

Using SNMP traps as RADIUS requests and SNMP writes as RADIUS responses,
SNMP could have done the whole trick of dynamic service provisioning;
nothing like RADIUS would theoretically be needed at all.

I don't believe it was just an historic error or a case of
not-invented-here on the part of Livingston that RADIUS was designed.
If it was an error, that error surely has never seen any attempt of
correction in the market place so far.

Even when RADIUS was reaching some of its limits, people came up with
DIAMETER, instead of encouraging people to use SNMP instead.

If you want to spend time on another research on the reasons for that
(hint: RADIUS is successful because it's so terribly *pragmatic*; we may
need to limit that a bit, but not too much or we'll suffocate it), then
that's fine, but if you suggest we embark on that I never want to hear
one deadline or time based argument to end a technical discussion again.
;-)

> If the eventual consensus of the WG is that individually addressable
> elements of a structure are not our cup of tea for attribute encoding
> guidelines, and that we really want to formalize the custom octet
> packing method for attribute encoding, then I could live with that, if
> it were algorithmic and predictable, from one attribute to another.  One
> way to make such a scheme predictable would be to mimic the way a
> specified reference implementation of a C language complier, on a
> specified reference CPU architecture, would encode a C structure
> definition in physical memory, and simply clone that encoding method.

Splitting of values at arbitrary octet boundaries can be defined with
two parameters and two flags per subvalue, without looking at CPUs or
compilers at all.

a. You have the offset of each subvalue, either given in octets relative to
the beginning or the end of the outer value; and 

b. you have the length of each subvalue, given in octets relative to the
beginning or the end of the outer value.

That's it. No reference to anything else is neccesary. If you have those
values, then *why* those values were chosen (because data type X wants
to be aligned at multiples of Y and has width Z) is irrelevant; you can
still obtain or position the data. Also keep in mind that interpretation
of the obtained octets as a certain data type happens at a higher level.

Then, if multiple subvalues are to have variable lengths, the value
effectively either contains a set of TLVs (possibly with implicit Ts) or
a set of delimited values (less optimal in many cases, because the
values cannot contain the delimiter, requiring an encoding layer on top
to deal with (un)escaping).

The parameters to walk any sane list of TLVs consist of:

a. the offset of a big-endian length field, 
b. the size of that length field, 
c. the offset of the value itself, 
d. the size of the value relative to the value given by the length field, and 
e. the offset of the next TLV given as an adjustment and padding count 
   relative to the value given by the length field.

(all offsets and sizes in octets, all offsets relative to the start of
the TLV).

Those parameters allow you to walk RADIUS, DIAMETER, EAP, my Extended
Attribute proposal and almost all RADIUS VSAs seen in the wild, without
any specific code.

> One could handle the on-the-wire endian-ness with a simple mechanism
> such as the host-to-net and net-to-host macros (e.g. htonl, ntohl, etc).

That's also a nonambiguous mathematical operation that is easily defined
without reference to any (reference) implementation. Network order is
Network order, that is, most significant octet first, and I don't see
why anyone should use anything else on the Network.

> Any way we go, I'd *much* rather reach consensus on design guidelines
> and then be able to review proposed RADIUS extensions I-Ds against
> those concrete best current practices, rather than make ad-hoc
> evaluations of each new attribute against the personal opinions of the
> day.

Agreed. My most important issue is that I think that Section 7 of the
design guidelines draft depends on the extended attribute format, not
the other way around.

The main substance of the draft provides guidance for the design of that
format, but after the format is agreed upon, then the format should provide
the framework for further style documents and design recommendations for
attributes that use the new format.

(Legenda, for people that have just tuned in and haven't gone away or
fallen asleep yet: those are 'Extended [RADIUS] Attributes', which have
a new attribute header format (which is under debate), of which one or
more exist in a single virtual field in the RADIUS packet, created by
the concatenation of all instances of the 'Extended-Attribute', a la
EAP-Message -- at least that much we agree upon, I think).

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send 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: Thu, 16 Mar 2006 22:58:58 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 18:06:33 -0500
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> I find it incomprehensible that the DIAMETER format would not need any
> evaluation against the alternatives on the merits, but that people can
> just wave their hands and say, there's already some diameter parsing
> code in many RADIUS server's that support TTLS in some form or other, so
> hey, 'tis the only sensible road ahead.

  s/only/proven working, implemented, deployed, and functional/

  If there are other alternatives, they should be explored, of course.
But the diameter format, while wasteful of space in the RADIUS packet,
*is* a proven one.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 16 Mar 2006 22:32:24 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 17:40:06 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> I see so you PREFER that work that has complex attribute not be done in
> RADEXT.

  That is not what I said, and not what I want.

> You would be upset if you got the beef.  Right?

  I'm starting to get upset that my point isn't getting across.

  Let's stop this.  It's not productive.

  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, 16 Mar 2006 22:28:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576
Date: Thu, 16 Mar 2006 14:28:11 -0800

Note the text from the VLAN/Priority document on a similar subject:

1.3.  Attribute Interpretation

   If a NAS conforming to this specification receives an Access-Accept
   packet containing an attribute defined in this document which it
   cannot apply, it MUST act as though it had received an Access-Reject.

   Similarly, [RFC3576] requires that a NAS receiving a  CoA-Request
   containing an unsupported attribute reply with a CoA-NAK.  It is
   recommended that an Error-Cause attribute with value set to
   "Unsupported Attribute" (401) be included in the packet.  As noted in
   [RFC3576], authorization changes are atomic so that this situation
   does not result in session termination and the pre-existing
   configuration remains unchanged.  As a result, no accounting packets
   should be generated.

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>Subject: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and 
>RFC 3576
>Date: Thu, 16 Mar 2006 14:12:04 -0800
>
>The text of Issue 167 is enclosed below.   The proposed resolution is as 
>follows:
>
>In Section 1.4, change:
>
>  1.4 Attribute Interpretation
>
>     Unless otherwise noted in the individual description of an
>     attribute contained herein, a NAS that conforms to this
>     specification and receives an Access-Accept message that contains
>     an attribute from this document that it cannot apply MUST
>     interpret this though an Access-Reject had been sent and MUST
>     terminate the session.  If accounting is enabled on the NAS, it
>     MUST generate an Accounting-Request(Stop) message upon session
>     termination.
>
>     Similarly, if a NAS conforming to this specification and also
>     conforming to RFC 3576 [RFC3576] receives a CoA message that
>     contains an attribute from this document that it cannot apply, it
>     MUST NOT terminate the session and MUST generate a CoA-NAK packet
>     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
>     accounting is enabled on the NAS, it MUST NOT generate an
>     Accounting-Request(Stop) message in such instances.
>
>To:
>
>  1.4 Attribute Interpretation
>
>     Unless otherwise noted in the individual description of an
>     attribute contained herein, a NAS that conforms to this
>     specification and receives an Access-Accept message that contains
>     an attribute from this document that it cannot apply MUST
>     interpret this though an Access-Reject had been sent and MUST
>     terminate the session.
>
>     Similarly, if a NAS conforming to this specification and also
>     conforming to RFC 3576 [RFC3576] receives a CoA message that
>     contains an attribute from this document that it cannot apply, it
>     MUST NOT terminate the session and MUST generate a CoA-NAK packet.
>
>-----------------------------------------------------------------------------------------------------
>Issue 167: Compatibility with RFC 2866 and RFC 3576
>Submitter names: Bernard Aboba
>Submitter email address: [email-masked]
>Date first submitted: January 30, 2006
>Reference:
>Document: IEEE 802-01
>Comment type: Technical
>Priority: S
>Section: 1.4
>Rationale/Explanation of issue:
>
>Section 1.4 states:
>
>  1.4 Attribute Interpretation
>
>     Unless otherwise noted in the individual description of an
>     attribute contained herein, a NAS that conforms to this
>     specification and receives an Access-Accept message that contains
>     an attribute from this document that it cannot apply MUST
>     interpret this though an Access-Reject had been sent and MUST
>     terminate the session.  If accounting is enabled on the NAS, it
>     MUST generate an Accounting-Request(Stop) message upon session
>     termination.
>
>     Similarly, if a NAS conforming to this specification and also
>     conforming to RFC 3576 [RFC3576] receives a CoA message that
>     contains an attribute from this document that it cannot apply, it
>     MUST NOT terminate the session and MUST generate a CoA-NAK packet
>     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
>     accounting is enabled on the NAS, it MUST NOT generate an
>     Accounting-Request(Stop) message in such instances.
>RFC 2866 does not specify the generation of Accounting Stop messages 
>resulting
>from Access-Reject packets.  This document is therefore requiring RADIUS
>accounting clients to generate accounting records in circumstances where
>they would not otherwise do so.  This raises the question of why
>this particular set of attributes would cause a special case modification
>to RFC 2866.  Here is what RFC 3576 has to say about receipt of attributes 
>in a CoA-Request:
>
>  If one or more authorization changes specified in a CoA-Request
>  cannot be carried out, or if one or more attributes or attribute-
>  values is unsupported, a CoA-NAK MUST be sent.
>
>On inclusion of Error-Cause attributes:
>
>     It is possible that the NAS cannot honor Disconnect-Request or
>     CoA-Request messages for some reason.  The Error-Cause Attribute
>     provides more detail on the cause of the problem.  It MAY be
>     included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
>     messages.
>
>Since inclusion of an Error-Cause attribute is generally optional, the
>second paragraph mandates behavior not required by RFC 3576.
>
>
>
>--
>to unsubscribe send 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, 16 Mar 2006 22:27:34 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 17:29:38 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

I see so you PREFER that work that has complex attribute not be done in
RADEXT.

If the waiter said:  " Would you prefer the chicken or the beef"

and you said to the waiter:  " I prefer the chicken"

You would be upset if you got the beef.  Right?

=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 4:29 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Alan DeKok" <[email-masked]> wrote:
> > And you also said this: right?
> > > > >   If the content of an attribute is a complex structure =
as=3D20=20
> > > > > determined by the application, I would *prefer* that the=3D20
> > > structure=3D20
> > > > > is defined elsewhere, and the RADIUS docs simply reference it.
> >=20
> > Defined elsewhere means to me its forbiden in RADIUS.
>=20
>   prefer !=3D forbid.
>=20
>   Please stop claiming I'm trying to forbid complex attributes.
>=20
>   Alan DeKok.
>=20

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

Delivery-date: Thu, 16 Mar 2006 22:23:47 +0000
Content-class: urn:content-classes:message
Subject: Extended attribute formats (was RE: New Technical Issues RE: WG  last call in progress on VLAN/Priority Draft)
Date: Thu, 16 Mar 2006 17:23:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

It would be helpful to change the subject line to accurately reflect the
topic.

Avi Lior writes...

> Anyway most of the discussion today is a repeat of the discusssions we
> had before (rehash).=20

Yes.  We failed to reach consensus the previous time, so we are destined
to continue the discussion until we reach one.  There are WG milestones
that are dependent upon reaching such a consensus.

> Most of the people changed (it seem) except for David Nelson.

That's not entirely true.  I won't repeat my comments, but in
https://psg.com/lists/radiusext/2006/msg00302.html
I indicated some options, my preferences, but also that my ultimate
desire that we reach a consensus on *something* concrete and useful in
the way of design guidelines (and extended attribute format, if
required).

--
to unsubscribe send a message 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, 16 Mar 2006 22:12:22 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576
Date: Thu, 16 Mar 2006 14:12:04 -0800

The text of Issue 167 is enclosed below.   The proposed resolution is as 
follows:

In Section 1.4, change:

  1.4 Attribute Interpretation

     Unless otherwise noted in the individual description of an
     attribute contained herein, a NAS that conforms to this
     specification and receives an Access-Accept message that contains
     an attribute from this document that it cannot apply MUST
     interpret this though an Access-Reject had been sent and MUST
     terminate the session.  If accounting is enabled on the NAS, it
     MUST generate an Accounting-Request(Stop) message upon session
     termination.

     Similarly, if a NAS conforming to this specification and also
     conforming to RFC 3576 [RFC3576] receives a CoA message that
     contains an attribute from this document that it cannot apply, it
     MUST NOT terminate the session and MUST generate a CoA-NAK packet
     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
     accounting is enabled on the NAS, it MUST NOT generate an
     Accounting-Request(Stop) message in such instances.

To:

  1.4 Attribute Interpretation

     Unless otherwise noted in the individual description of an
     attribute contained herein, a NAS that conforms to this
     specification and receives an Access-Accept message that contains
     an attribute from this document that it cannot apply MUST
     interpret this though an Access-Reject had been sent and MUST
     terminate the session.

     Similarly, if a NAS conforming to this specification and also
     conforming to RFC 3576 [RFC3576] receives a CoA message that
     contains an attribute from this document that it cannot apply, it
     MUST NOT terminate the session and MUST generate a CoA-NAK packet.

-----------------------------------------------------------------------------------------------------
Issue 167: Compatibility with RFC 2866 and RFC 3576
Submitter names: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 30, 2006
Reference:
Document: IEEE 802-01
Comment type: Technical
Priority: S
Section: 1.4
Rationale/Explanation of issue:

Section 1.4 states:

  1.4 Attribute Interpretation

     Unless otherwise noted in the individual description of an
     attribute contained herein, a NAS that conforms to this
     specification and receives an Access-Accept message that contains
     an attribute from this document that it cannot apply MUST
     interpret this though an Access-Reject had been sent and MUST
     terminate the session.  If accounting is enabled on the NAS, it
     MUST generate an Accounting-Request(Stop) message upon session
     termination.

     Similarly, if a NAS conforming to this specification and also
     conforming to RFC 3576 [RFC3576] receives a CoA message that
     contains an attribute from this document that it cannot apply, it
     MUST NOT terminate the session and MUST generate a CoA-NAK packet
     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
     accounting is enabled on the NAS, it MUST NOT generate an
     Accounting-Request(Stop) message in such instances.
RFC 2866 does not specify the generation of Accounting Stop messages 
resulting
from Access-Reject packets.  This document is therefore requiring RADIUS
accounting clients to generate accounting records in circumstances where
they would not otherwise do so.  This raises the question of why
this particular set of attributes would cause a special case modification
to RFC 2866.  Here is what RFC 3576 has to say about receipt of attributes 
in a CoA-Request:

  If one or more authorization changes specified in a CoA-Request
  cannot be carried out, or if one or more attributes or attribute-
  values is unsupported, a CoA-NAK MUST be sent.

On inclusion of Error-Cause attributes:

     It is possible that the NAS cannot honor Disconnect-Request or
     CoA-Request messages for some reason.  The Error-Cause Attribute
     provides more detail on the cause of the problem.  It MAY be
     included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
     messages.

Since inclusion of an Error-Cause attribute is generally optional, the
second paragraph mandates behavior not required by RFC 3576.

--
to unsubscribe send 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: Thu, 16 Mar 2006 21:27:22 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 16:35:04 -0500
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> Although the use of a Diameter header would allow for larger
> attributes, the increase in overhead means that there is actually
> less space available for attributes.

  Agreed.

  Do you have data on existing deployments where the 4k limit in
RADIUS is insufficient?

  I can only recall running into it once in the past decade.  The
situation was where a vendor had a non-standard string encoding for
attributes, and the customer wanted to send many of them.  In that
case, if the vendor had chosen to use a packed format, the 4k limit
would have been sufficient.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 16 Mar 2006 21:21:30 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 16:29:00 -0500
Message-Id: <[email-masked]>

"Alan DeKok" <[email-masked]> wrote:
> And you also said this: right?
> > > >   If the content of an attribute is a complex structure as=20
> > > > determined by the application, I would *prefer* that the=20
> > structure=20
> > > > is defined elsewhere, and the RADIUS docs simply reference it.
> 
> Defined elsewhere means to me its forbiden in RADIUS.

  prefer != forbid.

  Please stop claiming I'm trying to forbid complex attributes.

  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, 16 Mar 2006 21:05:54 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 13:05:39 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> supposedly scribbled:

...

> I would have thought that 4096 was quite generous, but I lack recent
> operational experience.  So I appeal to the group:  What's the
> largest RADIUS message that's been seen in the wild?  Are we anywhere
> close to being constrained by the 4096 limit, which we agree cannot
> be changed?=20

I wouldn't bring it up were it not the case.  In fact, at this very =
moment I am tasked w/trying to figure out how to send messages larger =
than the RADIUS limit (easy in Diameter, possibly impossible in RADIUS) =
in something like a reasonable fashion.  This is just the latest case:  =
IIRC, one of the major goals of the original RADIUS v2 (nee Diameter) =
effort was to get rid of the 4096 limit.  That was a _long_ time ago...
  =20
>=20
> I would also point out that we are not suggesting that all future
> RADIUS attributes use the Diameter format.  Only those that need more
> than 253 bytes, use a Diameter data type (including Grouped), or have
> type number greater than 255 would need to do so.  =20
>=20
> Regards,
> Barney

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:46:48 +0000
Date: Thu, 16 Mar 2006 15:46:38 -0500
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

On Thu, Mar 16, 2006 at 12:27:18PM -0800, Glen Zorn (gwz) wrote:
> 
> I have given my reasoning several times, but I will repeat myself
> again: the Diameter AVP structure was designed with the fact in
> mind that Diameter messages are virtually unlimited in length.  For
> this reason, the header could be as big as desired, with little
> concern for overhead.  RADIUS messages, however, are strictly
> constrained in length and I've not seen any realistic scheme for
> expanding them in a backwards-compatible fashion.  Attribute overhead
> _is_ an issue in RADIUS; every octet taken for an AVP header is one
> less available for actual data.  Although the use of a Diameter
> header would allow for larger attributes, the increase in overhead
> means that there is actually less space available for attributes.

I would have thought that 4096 was quite generous, but I lack recent
operational experience.  So I appeal to the group:  What's the largest
RADIUS message that's been seen in the wild?  Are we anywhere close
to being constrained by the 4096 limit, which we agree cannot be changed?

I would also point out that we are not suggesting that all future RADIUS
attributes use the Diameter format.  Only those that need more than 253
bytes, use a Diameter data type (including Grouped), or have type number
greater than 255 would need to do so.

Regards,
Barney

--
to unsubscribe send a message 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, 16 Mar 2006 20:40:52 +0000
Date: Thu, 16 Mar 2006 21:40:26 +0100
From: Emile van Bergen <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: Barney Wolff <[email-masked]>, Alan DeKok <[email-masked]>, [email-masked], Avi Lior <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Mail-Followup-To: "Glen Zorn (gwz)" <[email-masked]>, Barney Wolff <[email-masked]>, Alan DeKok <[email-masked]>, [email-masked], Avi Lior <[email-masked]>

Hi,

On Thu, Mar 16, 2006 at 12:12:20PM -0800, Glen Zorn (gwz) wrote:

> Barney Wolff <> supposedly scribbled:
> 
> > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote:
> >> 
> >> Also I resent somewhat the push now is so much that it ignores what
> >> we did a two years ago.  Based on discussion it was Jari who proposed
> >> encoding RADIUS attributes using Diameter syntax (I seem to recall
> >> that one of you guys were taking credit for that).
> > 
> > Just so we're clear, Alan did not "take" credit for it.  I assigned
> > credit to him because that's how I first heard the idea, and indeed a
> > search of radext archives shows email from him suggesting it in Feb
> > 2005.  But of course, if you or Jari (or anyone) can point me to a
> > prior discussion of the idea of using the Diameter attribute header
> > format, I will be glad to correct the acknowledgment.  
> 
> Well, you can give me credit for being virtually the only person saying that this is a Very Bad Idea...

Virtually, perhaps, but count me in as well.

If DIAMETER would do all RADIUS is lacking, it would have known much
stronger adoption.

This WGs very existence, how reluctantly it was started, is testament
that people rather build upon RADIUS than look at DIAMETER for their
solutions.

I find it then entirely foolish to suggest that a blanket transport
mechanism for DIAMETER inside RADIUS would solve all our issues. 

I find it incomprehensible that the DIAMETER format would not need any
evaluation against the alternatives on the merits, but that people can
just wave their hands and say, there's already some diameter parsing
code in many RADIUS server's that support TTLS in some form or other, so
hey, 'tis the only sensible road ahead.

Really, is that all we can muster these days?

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 16 Mar 2006 20:40:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages
Date: Thu, 16 Mar 2006 12:40:37 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Sanchez, Mauricio" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Sanchez, Mauricio <mailto:[email-masked]> supposedly scribbled:

> Glenn questioned..

...

> Only zero or one user-priority-table attribute is allowed.  You must
> be thinking about Egress-VLAN-Name attribute.=20

Yup.

>=20
> The NAS may have the capability to allow a user session to be
> associated with multiple VLANs.  By sending multiple vlan attributes
> up to the server (i.e. the "hints"), the server finds out what is a
> possible set of VLANs the session may be assigned.  =20

OK.

>=20
> MS

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:35:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages
Date: Thu, 16 Mar 2006 12:34:45 -0800
From: "Sanchez, Mauricio" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Glenn questioned..=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Thursday, March 16, 2006 12:16 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: RE: Proposed Resolution to Issue 178: Allowing Hints=20
> in Request Messages
>=20
> Bernard Aboba <> supposedly scribbled:
>=20
> I'm fine with the hint thing, but I wonder why you would need=20
> to send, e.g., multiple Egress-VLANID or User-Priority-Table=20
> attributes as hints.  Would not one of each suffice?

Only zero or one user-priority-table attribute is allowed.  You must be
thinking about Egress-VLAN-Name attribute. =20

The NAS may have the capability to allow a user session to be associated
with multiple VLANs.  By sending multiple vlan attributes up to the
server (i.e. the "hints"), the server finds out what is a possible set
of VLANs the session may be assigned. =20

MS

--
to unsubscribe send a message 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, 16 Mar 2006 20:34:56 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 15:37:01 -0500
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Alan DeKok" <[email-masked]>, <[email-masked]>

Take a look at: IETF 60  August 2004.

Presentation:
http://www3.ietf.org/proceedings/04aug/slides/radextt-6/sld8.htm

But even before that we had that proposal from Jari.  I remember the
email distinctly.  And here is that now forgotten email
http://ops.ietf.org/lists/radiusext/2004/msg00441.html

Anyway most of the discussion today is a repeat of the discusssions we
had before (rehash).  Most of the people changed (it seem) except for
David Nelson.=20

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20
> Sent: Thursday, March 16, 2006 3:07 PM
> To: Avi Lior
> Cc: Alan DeKok; [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote:
> >=20
> > Also I resent somewhat the push now is so much that it=20
> ignores what we=20
> > did a two years ago.  Based on discussion it was Jari who proposed=20
> > encoding RADIUS attributes using Diameter syntax (I seem to recall=20
> > that one of you guys were taking credit for that).
>=20
> Just so we're clear, Alan did not "take" credit for it.  I=20
> assigned credit to him because that's how I first heard the=20
> idea, and indeed a search of radext archives shows email from=20
> him suggesting it in Feb 2005.  But of course, if you or Jari=20
> (or anyone) can point me to a prior discussion of the idea of=20
> using the Diameter attribute header format, I will be glad to=20
> correct the acknowledgment.
>=20
> Regards,
> Barney
>=20

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

Delivery-date: Thu, 16 Mar 2006 20:30:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Thu, 16 Mar 2006 12:30:46 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Sanchez, Mauricio" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Sanchez, Mauricio <mailto:[email-masked]> supposedly scribbled:

...

> Can we agree, with whatever associated cringing, and accept the
> current state of the VLAN draft data types as acceptable?  They are
> at best a continuation of the ad-hoc design legacy and at worst an
> ugly wart that will stand out once clear design guidelines are
> defined.  I don't think anyone can pragmatically disagree that going
> forward with the VLAN draft's data types will cause insurmountable
> pain to implementers. It's only business as usual for RADIUS.     =20
>=20
> My vote is to accept the draft as is on this matter.

OK

>=20
> Cheers,
> MS

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:28:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Thu, 16 Mar 2006 12:26:45 -0800
From: "Sanchez, Mauricio" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard and Glen stated:=20

> Bernard Aboba <> supposedly scribbled:
>=20
> > The text of Issue 180 (and some of the subsequent discussion) is=20
> > enclosed below.
> >=20
> > The proposed resolution is to change "VLAN Tag" to "VLAN Flag"
> > everywhere in the document.=20
>=20
> Sounds reasonable to me.

I concur.=20

>=20
> >=20
> > In looking at the mailing list discussion, I did not detect=20
> consensus=20
> > for making other changes.
>=20
> Although I don't think that the discussion is altogether=20
> complete, I would agree with your assessment of its progress thus far.

We've got a chicken and egg problem here.   Agreement on what to do with
complex/compound/whatever-you-want-to-call-them RADIUS attributes is not
going to get solved using the VLAN draft as the vehicle.  It's something
that Dave pointed out is best addressed in design guidelines draft.
Yet, the design guideline draft and its associated discussion are only
really going to happen after the VLAN draft milestone. =20

While I do agree that it would be admirable if we could come to a
suitable general solution to the data problem, I don't think we're going
to get to one quick enough.  It does appear, however, that people do
agree that the past design behavior for RADIUS attributes, while ad-hoc
and non-optimal, has worked so far. =20

Can we agree, with whatever associated cringing, and accept the current
state of the VLAN draft data types as acceptable?  They are at best a
continuation of the ad-hoc design legacy and at worst an ugly wart that
will stand out once clear design guidelines are defined.  I don't think
anyone can pragmatically disagree that going forward with the VLAN
draft's data types will cause insurmountable pain to implementers. It's
only business as usual for RADIUS.

My vote is to accept the draft as is on this matter.

Cheers,
MS

--
to unsubscribe send a message 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, 16 Mar 2006 20:27:52 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 12:27:18 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> supposedly scribbled:

...

>> Well, you can give me credit for being virtually the only person
>> saying that this is a Very Bad Idea...=20
>=20
> Credit would certainly be due if you would give your reasoning and it
> was convincing.=20

I have given my reasoning several times, but I will repeat myself again: =
the Diameter AVP structure was designed with the fact in mind that =
Diameter messages are virtually unlimited in length.  For this reason, =
the header could be as big as desired, with little concern for overhead. =
 RADIUS messages, however, are strictly constrained in length and I've =
not seen any realistic scheme for expanding them in a =
backwards-compatible fashion.  Attribute overhead _is_ an issue in =
RADIUS; every octet taken for an AVP header is one less available for =
actual data.  Although the use of a Diameter header would allow for =
larger attributes, the increase in overhead means that there is actually =
less space available for attributes.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:17:21 +0000
Date: Thu, 16 Mar 2006 15:17:15 -0500
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

On Thu, Mar 16, 2006 at 12:12:20PM -0800, Glen Zorn (gwz) wrote:
> Barney Wolff <> supposedly scribbled:
> 
> > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote:
> >> 
> >> Also I resent somewhat the push now is so much that it ignores what
> >> we did a two years ago.  Based on discussion it was Jari who proposed
> >> encoding RADIUS attributes using Diameter syntax (I seem to recall
> >> that one of you guys were taking credit for that).
> > 
> > Just so we're clear, Alan did not "take" credit for it.  I assigned
> > credit to him because that's how I first heard the idea, and indeed a
> > search of radext archives shows email from him suggesting it in Feb
> > 2005.  But of course, if you or Jari (or anyone) can point me to a
> > prior discussion of the idea of using the Diameter attribute header
> > format, I will be glad to correct the acknowledgment.  
> 
> Well, you can give me credit for being virtually the only person saying that this is a Very Bad Idea...

Credit would certainly be due if you would give your reasoning and it
was convincing.

> Hope this helps,

See above.

Regards,
Barney

--
to unsubscribe send a message 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, 16 Mar 2006 20:16:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages
Date: Thu, 16 Mar 2006 12:15:47 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

I'm fine with the hint thing, but I wonder why you would need to send, =
e.g., multiple Egress-VLANID or User-Priority-Table attributes as hints. =
 Would not one of each suffice?

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:14:20 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 15:16:29 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan,

You said this:

>   I'm not sure how you conclude that I'm trying to forbid=20
> complex attributes. =20

And you also said this: right?
> > >   If the content of an attribute is a complex structure as=20
> > > determined by the application, I would *prefer* that the=20
> structure=20
> > > is defined elsewhere, and the RADIUS docs simply reference it.

Defined elsewhere means to me its forbiden in RADIUS.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 2:54 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Avi Lior" <[email-masked]> wrote:
> > >   If the content of an attribute is a complex structure as=20
> > > determined by the application, I would *prefer* that the=20
> structure=20
> > > is defined elsewhere, and the RADIUS docs simply reference it.
> >=20
> > I don't agree.  Why should that be?
>=20
>   RFC 3576
> ...
> 3.1.  EAP-Message
>=20
>    Description
>=20
>       This attribute encapsulates EAP [RFC2284] ...
>=20
>   Instead of having a normitive reference, let's cut & paste=20
> big chunks of ASCII art from RFC 2284 here.
>=20
>   Oh, wait...
>=20
> > Again,  what you are saying if it doesn't fit into my=20
> dictionary then=20
> > I don't think its RADIUS.
>=20
>   I'm pretty clear that that's *not* what I'm saying.  I've=20
> been trying to convince you of this, but for some reason I'm=20
> not succeeding.
>=20
>   I'm not sure how you conclude that I'm trying to forbid=20
> complex attributes.  Perhaps I should stop protesting, and=20
> just let you believe what you want about my opinions.  But=20
> *please* don't claim publicly I'm trying to forbid complex=20
> attributes.  That is demonstratably not true.  Just read my messages.
>=20
>   Alan DeKok.
>=20

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

Delivery-date: Thu, 16 Mar 2006 20:12:54 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 12:12:20 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Alan DeKok" <[email-masked]>, <[email-masked]>, "Avi Lior" <[email-masked]>

Barney Wolff <> supposedly scribbled:

> On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote:
>>=20
>> Also I resent somewhat the push now is so much that it ignores what
>> we did a two years ago.  Based on discussion it was Jari who proposed
>> encoding RADIUS attributes using Diameter syntax (I seem to recall
>> that one of you guys were taking credit for that).
>=20
> Just so we're clear, Alan did not "take" credit for it.  I assigned
> credit to him because that's how I first heard the idea, and indeed a
> search of radext archives shows email from him suggesting it in Feb
> 2005.  But of course, if you or Jari (or anyone) can point me to a
> prior discussion of the idea of using the Diameter attribute header
> format, I will be glad to correct the acknowledgment. =20

Well, you can give me credit for being virtually the only person saying =
that this is a Very Bad Idea...
  =20
>=20
> Regards,
> Barney

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 16 Mar 2006 20:06:52 +0000
Date: Thu, 16 Mar 2006 15:06:33 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote:
> 
> Also I resent somewhat the push now is so much that it ignores what we
> did a two years ago.  Based on discussion it was Jari who proposed
> encoding RADIUS attributes using Diameter syntax (I seem to recall that
> one of you guys were taking credit for that).

Just so we're clear, Alan did not "take" credit for it.  I assigned
credit to him because that's how I first heard the idea, and indeed
a search of radext archives shows email from him suggesting it in
Feb 2005.  But of course, if you or Jari (or anyone) can point me to
a prior discussion of the idea of using the Diameter attribute header
format, I will be glad to correct the acknowledgment.

Regards,
Barney

--
to unsubscribe send a message 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, 16 Mar 2006 19:57:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages
Date: Thu, 16 Mar 2006 11:57:06 -0800
From: "Sanchez, Mauricio" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

This is satisfactory and issue can be closed once document is updated.

MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, March 16, 2006 10:06 AM
> To: [email-masked]
> Subject: Proposed Resolution to Issue 178: Allowing Hints in=20
> Request Messages
>=20
> The text of Issue 178 is enclosed below.  The proposed=20
> resolution is to accept the changes.
>=20
> --------------------------------------------------------------
> ------------------------------------------------------------------
> Issue 178: Allowing Hints in Request Messages Submitter name:=20
> Mauricio Sanchez Submitter email address:=20
> [email-masked] Date first submitted: March 6, 2006
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00225.html
> Document: draft-ietf-radext-vlan-00.txt
> Comment type: T
> Priority: 2
> Section: Table in section 3, individual attributes=20
> Rationale/Explanation of issue:
> Draft-ietf-radext-vlan-00 does not allow the new attributes=20
> to be sent in ACCESS-REQUEST messages.  If allowed,=20
> attributes in the REQUEST message could serve as 'hints' to=20
> the RADIUS server during the decision making process.
> Requested change:  Allow attributes to be sent ACCESS-REQUEST=20
> message Proposed changes to the document.
>=20
> - Descriptions of individual attribute descriptions would be=20
> changed to allow attributes in access request, as follows:
> Multiple <attr_name> attributes MAY be included in an=20
> Access-Request, Access-Accept or CoA-Request packet; this=20
> attribute MUST NOT be sent within an Access-Challenge,=20
> Access-Reject, Disconnect-Request, Disconnect-ACK,=20
> Disconnect-NAK, CoA-ACK, or CoA-NAK.
>=20
> -Table in section 3 would be changed to:
>=20
>    Access-   Access-  Access-  Access-    CoA-
>    Request   Accept   Reject   Challenge  Req     #    Attribute
>        0+      0+       0        0        0+    TBD  Egress-VLANID
>        0-1     0-1      0        0        0-1   TBD  Ingress-Filters
>        0+      0+       0        0        0+    TBD  Egress-VLAN-Name
>        0-1     0-1      0        0        0-1   TBD =20
> User-Priority-Table
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Thu, 16 Mar 2006 19:46:11 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 14:53:47 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> >   If the content of an attribute is a complex structure as
> > determined by the application, I would *prefer* that the
> > structure is defined elsewhere, and the RADIUS docs simply
> > reference it.
> 
> I don't agree.  Why should that be?

  RFC 3576
...
3.1.  EAP-Message

   Description

      This attribute encapsulates EAP [RFC2284]
...

  Instead of having a normitive reference, let's cut & paste big
chunks of ASCII art from RFC 2284 here.

  Oh, wait...

> Again,  what you are saying if it doesn't fit into my dictionary then I
> don't think its RADIUS.

  I'm pretty clear that that's *not* what I'm saying.  I've been
trying to convince you of this, but for some reason I'm not
succeeding.

  I'm not sure how you conclude that I'm trying to forbid complex
attributes.  Perhaps I should stop protesting, and just let you
believe what you want about my opinions.  But *please* don't claim
publicly I'm trying to forbid complex attributes.  That is
demonstratably not true.  Just read my messages.

  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, 16 Mar 2006 19:22:12 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 14:24:19 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

See inline....=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 1:43 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Avi Lior" <[email-masked]> wrote:
> > That is fine.  But why should we balk when we are faced=20
> with a complex=20
> > attribute as required by a complex application. The=20
> argument that it=20
> > breaks the dictionary should NOT stop the work going forward.  The=20
> > Dictionary should only parse it up to String.  Let the application=20
> > decode the rest.
>=20
>   Agreed.
>=20
>   If the content of an attribute is a complex structure as=20
> determined by the application, I would *prefer* that the=20
> structure is defined elsewhere, and the RADIUS docs simply=20
> reference it.

I don't agree.  Why should that be?

>   The contention comes when more and more complex structures=20
> are shoe-horned into RADIUS attributes, where those=20
> structures have no definition outside of RADIUS.  In those=20
> cases, the preference is to use existing RADIUS types where possible.

Defining a RADIUS based RFC does not mean that your simple RADIUS server
has to implement that attribute.  It should though be able to transport
it pass-through though.  So it must be able to parse through that
attribute.

Again,  what you are saying if it doesn't fit into my dictionary then I
don't think its RADIUS.  The attributes do fit in the Dictionary  it
just that you have to go beyong the strings at a different layer.

So attributes like User-Name does not belong in RADIUS - by your logic.
Neither does 3162, CHAP etc.... Which all use encoding that are not
supported by RADIUS.

I think this logic is seriously flawed.

>   Where not, use the Diameter attribute format, and leverage=20
> it's grouping mechanism to get complicated structural relationships.
>

Which will also not be RADIUS....

=20
>   Alan DeKok.
>=20

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

Delivery-date: Thu, 16 Mar 2006 19:15:31 +0000
Content-class: urn:content-classes:message
Subject: RE: [Issue 168] split-out filter draft: IANA
Date: Thu, 16 Mar 2006 11:15:10 -0800
From: "Sanchez, Mauricio" <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>, <[email-masked]>

Change requested will be made.  Thanks for the in-depth review.

Cheers,
MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Friday, March 03, 2006 1:28 PM
> To: [email-masked]
> Subject: [Issue 168] split-out filter draft: IANA
>=20
>=20
> I see that draft-ietf-radext-filter-rules-00.txt fixes most=20
> of the editorial comments I made as part of issue 168.  I=20
> guess we can close this issue if the authors will just agree=20
> to fix this (at some point):
>=20
>  - The IANA section says the draft is allocating six
>    attributes, but it's only allocating two.
>=20
> Greg
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 16 Mar 2006 18:57:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Thu, 16 Mar 2006 10:57:32 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> The text of Issue 180 (and some of the subsequent discussion) is
> enclosed below.=20
>=20
> The proposed resolution is to change "VLAN Tag" to "VLAN Flag"
> everywhere in the document.=20

Sounds reasonable to me.

>=20
> In looking at the mailing list discussion, I did not detect consensus
> for making other changes.=20

Although I don't think that the discussion is altogether complete, I =
would agree with your assessment of its progress thus far.

>=20
> =
-------------------------------------------------------------------------=
---------------------------
> Issue 180: Misuse of Data Types
> Submitter name: Dave Nelson
> Submitter email address: [email-masked] Date first submitted:
> March 14, 2006=20
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html
> Document: VLAN/Priority -00
> Comment type: 'T'echnical
> Priority: '1' Should fix
> Section: 2.1.  Egress-VLANID
> Rationale/Explanation of issue:
>=20
> I had previously raised this issue, and the resolution was we could
> use a RADIUS data type of Integer, because only the VLANID (12-bit)
> portion would be used. =20
> Thus, this object could be thought  of as a range-limited integer.
> Since I see that we still have the VLAN Tag fields, that resolution
> falls apart.  I claim that this data object is not an Integer. =20
>=20
> Someone offered the suggestion that Integers are not simply the
> mathematical definition, i.e. the positive  and negative whole
> numbers and zero, that we all learned in high school. With all due
> respect,  =20
>=20
> I think that's patently wrong. It is true that one can write programs
> that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data
> structures using mask, bit-field, shift and rotate operations. =20
>=20
> I still claim that those data structures are *not* integers simply
> because they can be packed within the computer memory storage that is
> also used by integers. Hopefully, there is more to data modeling=20
> than the storage length in bits. :-)  =20
>=20
> We are currently having a debate on the RADEXT WG list about the
> issue of derived data types, and no  consensus has yet been reached.
> However, until such a consensus is reached, it seems most appropriate
> to follow the existing practice of defining derived data types as
> Strings, with the bit-fields described in the text. I think that
> over-loading base RADIUS data types with new meanings is
> inappropriate.     =20
>=20
> Given the relative timing of WGLC on this draft and the emerging
> consensus on RADIUS Attribute Design Guidelines, I think this is the
> best compromise. =20
>=20
> Requested change:
>=20
> OLD:
>=20
> Integer
>=20
> The Integer field is four octets in length. The format is described
> below:=20
>=20
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> VLAN Tag      |      Pad              |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> The VLAN Tag field is one octet in length, and indicates whether the
> frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad
> field is 12-bits in length and MUST be 0 (zero). The VLANID is
> 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.  =20
>=20
> NEW:
>=20
> String
>=20
> The String field is four octets in length. The format is described
> below:=20
>=20
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> VLAN Tag      |      Pad              |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> The VLAN Tag field is one octet in length, and indicates whether the
> frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad
> field is 12-bits in length and MUST be 0 (zero). The VLANID is
> 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.  =20
>=20
> Section: 2.3. Egress-VLAN-Name
> Rationale/Explanation of issue:
>=20
> I'm rather uncomfortable with the usage of the VLAN Tag field, as it
> seems to be at variance with the emerging WG consensus on complex or
> structured data types. Once we standardize this usage, there will be
> one more precedent in a RADIUS RFC to support ad-hoc data typing.  =20
> If that's what RADEXT ultimately recommends, then this will be fine.
> If the recommendation is to use a more formal method of aggregating
> structured data, this will be one more anomaly. =20
>=20
> VLAN Tag
>=20
> The VLAN tag field is one octet in length, and indicates whether the
> frames on the VLAN are tagged (0x31) or untagged (0x32).=20
>=20
> Requested change:
>=20
> I have no idea what (if any change) to request. Chalk this comment up
> as my personal lament over the process that RADEXT has followed --
> delaying consensus on attributes design to the point where we are
> standardizing new attributes using complex data types prior to having
> defined the design guidelines for complex data types.   =20
>=20
> Section 2.4 User-Priority-Table
> Rationale/Explanation of issue:
>=20
> With all due deference to the well understood "array - string
> duality" we find in programming languages such as C, I think that
> expressing a attribute whose value is an array in the form of a
> RADIUS String type is unfortunate, for the reasons expressed above.  =20
>=20
> Requested change:
>=20
> (See above.)
>=20
> The only way that I see to actually resolve my data typing / data
> modeling concerns is to delay sending any RADEXT work item that uses
> derived data types to the IESG until after we have sent the RADIUS
> Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG,
> and that approach is not compatible with our milestones.   =20
>=20
> [Glen Zorn]
> With all due respect, I think that you are the one doing the
> overloading:=20
> RFC 2568 says
>=20
> 	integer   32 bit unsigned value, most significant octet first.
>=20
> That's it.  No range, no interpretation, nothing else.
>=20
> [Emile Van Bergen]
>> I see nothing that indicates this data type is anything other than an
>> integer, typically expressed in a C language declaration as "unsigned
>> long".
>=20
> You're completely correct. And in the case of the VLAN attribute, it
> *does* contain an unsigned integer value, one that's calculated as
> follows:=20
>=20
> value =3D vlanflag * 16777216 + vlanid
>=20
> The reverse goes as follows:
>=20
> vlanflag =3D value / 16777216
> vlanid =3D value % 16777216
>=20
> (where
> * denotes unsigned integer multiplication,
> + denotes unsigned integer addition,
> / denotes unsigned integer division and
> % denotes taking the reminder of an unsigned integer division, all to
> be carried out on unsigned integers in the range 0 .. 2**32-1)=20
>=20
> I'm not believing that people on this list would have to be explained
> that shifting and masking bits are *not* magic operations that you
> can only perform if you program in assembly (or its portable flavour,
> C), but that those are normal mathematical operations on normal
> integers:   =20
> multiply and take remainder (by powers of 2).
>=20
> You can do that, I think, even in Java, SAP/r3, XSLT, SQL and
> whatever.=20
> This whole issue has nothing whatsoever to do with C structures.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send 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: Thu, 16 Mar 2006 18:35:31 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 13:43:10 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> That is fine.  But why should we balk when we are faced with a complex
> attribute as required by a complex application. The argument that it
> breaks the dictionary should NOT stop the work going forward.  The
> Dictionary should only parse it up to String.  Let the application
> decode the rest.

  Agreed.

  If the content of an attribute is a complex structure as determined
by the application, I would *prefer* that the structure is defined
elsewhere, and the RADIUS docs simply reference it.

  The contention comes when more and more complex structures are
shoe-horned into RADIUS attributes, where those structures have no
definition outside of RADIUS.  In those cases, the preference is to
use existing RADIUS types where possible.

  Where not, use the Diameter attribute format, and leverage it's
grouping mechanism to get complicated structural relationships.

  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, 16 Mar 2006 18:29:18 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 13:31:27 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

HI Alan,

Please see inline....=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 1:09 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Avi Lior" <[email-masked]> wrote:
> ...
>=20
>   I think we're agreeing on most things, and just nit-picking=20
> on details.  That being said, let's continue.

I agree.

> > But alan, you cant go on the assumption that you will only accept=20
> > non-binary "code" changes.
>=20
>   I'm not assuming that.  I'm assuming that, again, for the=20
> 99% common case, dictionary updates are enough to enable the=20
> server to deal with new attributes.  This has been true in my=20
> experience, in the last decade of working with RADIUS.

That is the past.....today RADIUS and AAA for that matter is being asked
to participate in more complex scenarios.  So we have to let go of the
past ---- let it go .... Let it go   ;-)

Examples of complicated AAA scenarios:

EAP.  RADIUS now has to have an EAP Authentication Server
Prepaid or Credit control
MIPv4
MIPv6
Redirection (complexity on client side)
=20
> > Some attributes -- like the prepaid -- or mobile ip -- EAP=20
> --- require=20
> > complex algorithms to be executed.  I doubt you can do them via=20
> > configuraiton files.
>=20
>   Which is why I never claimed you could.  Please, don't=20
> think I'm unaware of algorithm changes that require updates=20
> to the server binary.  I've mentioned that explicitely in=20
> previous messages.

OK.  I never claimed you are not aware.  But since the Application has
to parse the attribut anyway then on the transport layer why not just
deal with it as a string?
=20
> > Yes. I agree. But my parser in my product is very capable and can=20
> > handle more complex attribute structures then the other=20
> fellow.  So I=20
> > can restate your statement as "complex things should be simle to do"
>=20
>   If your parser can handle algorithm updates, too, more power to you.

>   The problem the dictionaries solve is, again, the 99%=20
> common case where a more complex parser just isn't necessary.

Yes in the old days ;-) for the simplest of applications.

> > Semantics are handled by clever policy files which use the=20
> attribute=20
> > to compute some outcome.  The policy files are NOT standard=20
> in RADIUS.
>=20
>   Agreed.  But again, the dictionaries (to a large extent)=20
> simplify policy engines by removing the requirement that the=20
> policy engines understand RADIUS attributes.  They don't. =20
> They just understand name to type mappings, and instances of=20
> named objects.

Sure.  But even in the Good Old Days of RADIUS  attributes like
User-name etc required complex parsing of the user-name usign Regular
expressions.  At least that was true in our deployements.  And our
deployements are never in the enterprise space.
=20
> > The bottom line is this:
> > We ought not make descision based on how complex or simple it is to=20
> > handle an attribute.  That is nuts.
>=20
>   I'm not sure why.  If an application can be supported by=20
> simply defining a new attribute, and requiring that the=20
> attribute be sent in a packet, then that application could be=20
> standardized with little discussion.

That is fine.  But why should we balk when we are faced with a complex
attribute as required by a complex application. The argument that it
breaks the dictionary should NOT stop the work going forward.  The
Dictionary should only parse it up to String.  Let the application
decode the rest.

>   If an application requires more complex changes to the=20
> protocol, then the decision to standardize it requires more=20
> discussion than the previous case.

Dictionary is not Protocol!!!

Application don't really change the protcol usually.  Even complex ones.
=20
>   Complexity *does* influence decisions.  Strongly.

I don't agree that complexity should influnce decision.  I think
uncessary complexity should be reduced.  But not to accept a RADIUs
feature because its too complex is not correct.  A RADIUS feature should
be accepted if it's need is demonstrated regardless of its complexity.

I agree that more complex application require more time to develop but
at the application level and not neccesarily at the protocol level.

And complex application does not necessarily mean a complex attribute.
A simple attribute carrying an integer may be associated with a complex
application.

=20
> > My original motivation for having a standard for complex attributes=20
> > was because people were encoding attribute using name value=20
> pairs such=20
> > as: in a String address=3D"24 oberon",phone=3D" ".  I wanted to=20
> stop that=20
> > because parsing these strings would slow every RADIUS server out=20
> > there, and it was wasting space.
>=20
>   Agreed completely.
>=20
> > Also I resent somewhat the push now is so much that it=20
> ignores what we=20
> > did a two years ago.  Based on discussion it was Jari who proposed=20
> > encoding RADIUS attributes using Diameter syntax (I seem to recall=20
> > that one of you guys were taking credit for that).
>=20
>   Sorry for any conflict... that wasn't the intent.
>=20
> > I think any other coding scheme is nuts and we should just move on=20
> > with diameter encoding.  Unless of course  there is already working=20
> > code as in the case of Prepaid.
>=20
>   Agreed.  Let's move forward on that basis.
>=20
>   Alan DeKok.
>=20

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

Delivery-date: Thu, 16 Mar 2006 18:28:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Strawman VLAN -01 document
Date: Thu, 16 Mar 2006 10:28:29 -0800

A version of the RADIUS VLAN/Priority document with all the proposed edits 
applied is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-01.txt

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

Delivery-date: Thu, 16 Mar 2006 18:15:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 180: Misuse of Data Types
Date: Thu, 16 Mar 2006 10:15:17 -0800

The text of Issue 180 (and some of the subsequent discussion) is enclosed 
below.

The proposed resolution is to change "VLAN Tag" to "VLAN Flag" everywhere in 
the document.

In looking at the mailing list discussion, I did not detect consensus for 
making other changes.

----------------------------------------------------------------------------------------------------
Issue 180: Misuse of Data Types
Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: March 14, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html
Document: VLAN/Priority -00
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.1.  Egress-VLANID
Rationale/Explanation of issue:

I had previously raised this issue, and the resolution was we could use a 
RADIUS data
type of Integer, because only the VLANID (12-bit) portion would be used. 
Thus, this object could be thought  of as a range-limited integer. Since I 
see that we still have the VLAN Tag fields, that resolution falls apart.  I 
claim that this data object is not an Integer.

Someone offered the suggestion that Integers are not simply the mathematical 
definition, i.e. the positive  and negative whole numbers and zero, that we 
all learned in high school. With all due respect,

I think that's patently wrong. It is true that one can write programs that 
treat 8-bit, 16-bit,
32-bit or 64-bit "integers" as packed data structures using mask, bit-field, 
shift and rotate operations.

I still claim that those data structures are *not* integers simply because 
they can be packed within
the computer memory storage that is also used by integers. Hopefully, there 
is more to data modeling  than the storage length in bits. :-)

We are currently having a debate on the RADEXT WG list about the issue of 
derived data types, and no  consensus has yet been reached. However, until 
such a consensus is reached, it seems most appropriate  to follow the 
existing practice of defining derived data types as Strings, with the 
bit-fields described in the text. I think that over-loading base RADIUS data 
types with new meanings is inappropriate.

Given the relative timing of WGLC on this draft and the emerging consensus 
on RADIUS Attribute Design Guidelines, I think this is the best compromise.

Requested change:

OLD:

Integer

The Integer field is four octets in length. The format is
described below:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag      |      Pad              |       VLANID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The VLAN Tag field is one octet in length, and indicates whether
the frames on the VLAN are tagged (0x31) or untagged (0x32). The
Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.

NEW:

String

The String field is four octets in length. The format is
described below:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag      |      Pad              |       VLANID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The VLAN Tag field is one octet in length, and indicates whether
the frames on the VLAN are tagged (0x31) or untagged (0x32). The
Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.

Section: 2.3. Egress-VLAN-Name
Rationale/Explanation of issue:

I'm rather uncomfortable with the usage of the VLAN Tag field, as it seems 
to be at variance
with the emerging WG consensus on complex or structured data types. Once we 
standardize
this usage, there will be one more precedent in a RADIUS RFC to support 
ad-hoc data typing.
If that's what RADEXT ultimately recommends, then this will be fine. If the 
recommendation
is to use a more formal method of aggregating structured data, this will be 
one more anomaly.

VLAN Tag

The VLAN tag field is one octet in length, and indicates whether
the frames on the VLAN are tagged (0x31) or untagged (0x32).

Requested change:

I have no idea what (if any change) to request. Chalk this comment up as my 
personal lament
over the process that RADEXT has followed -- delaying consensus on 
attributes design to the
point where we are standardizing new attributes using complex data types 
prior to having
defined the design guidelines for complex data types.

Section 2.4 User-Priority-Table
Rationale/Explanation of issue:

With all due deference to the well understood "array - string duality" we 
find in programming
languages such as C, I think that expressing a attribute whose value is an 
array in the form of
a RADIUS String type is unfortunate, for the reasons expressed above.

Requested change:

(See above.)

The only way that I see to actually resolve my data typing / data modeling 
concerns is to delay
sending any RADEXT work item that uses derived data types to the IESG until 
after we have sent
the RADIUS Design Guidelines and RADIUS Extended Attributes I-Ds to the 
IESG, and that approach
is not compatible with our milestones.

[Glen Zorn]
With all due respect, I think that you are the one doing the overloading: 
RFC 2568 says

	integer   32 bit unsigned value, most significant octet first.

That's it.  No range, no interpretation, nothing else.

[Emile Van Bergen]
>I see nothing that indicates this data type is anything other than an
>integer, typically expressed in a C language declaration as "unsigned
>long".

You're completely correct. And in the case of the VLAN attribute, it
*does* contain an unsigned integer value, one that's calculated as follows:

value = vlanflag * 16777216 + vlanid

The reverse goes as follows:

vlanflag = value / 16777216
vlanid = value % 16777216

(where
* denotes unsigned integer multiplication,
+ denotes unsigned integer addition,
/ denotes unsigned integer division and
% denotes taking the reminder of an unsigned integer division,
all to be carried out on unsigned integers in the range 0 .. 2**32-1)

I'm not believing that people on this list would have to be explained
that shifting and masking bits are *not* magic operations that you can
only perform if you program in assembly (or its portable flavour, C),
but that those are normal mathematical operations on normal integers:
multiply and take remainder (by powers of 2).

You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever.
This whole issue has nothing whatsoever to do with C structures.

--
to unsubscribe send a message 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, 16 Mar 2006 18:10:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed resolution to Issue 181: Review
Date: Thu, 16 Mar 2006 10:10:39 -0800

The text of Issue 181 is enclosed below.  The proposed resolution is as 
follows:

Add expansions of VLAN, RADIUS, NAS, etc.  Substitute RFC 4363 for RFC 2674.

Replace the terminology section with definitions taken from RFC 3748 and RFC 
4005:

Authenticator
The end of the link initiating EAP authentication. The term
authenticator is used in [RFC3748] and [IEEE-802.1X], and has the same 
meaning
in this document.

backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this
server typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X].

Network Access Server (NAS)
A device that provides an access
service for a user to a network.

Supplicant
The end of the link that responds to the authenticator in [IEEE-802.1X].

Rewrite the security considerations section as follows:

"This specification describes the use of RADIUS for purposes of
authentication, authorization and accounting in
networks supporting [IEEE 802.1X]. Threats and security
issues for this application are described in [RFC3579] and [RFC3580];
security issues encountered in roaming are described in
[RFC2607].

This document specifies new attributes that can be included in
existing RADIUS packets, which are protected as
described in [RFC3579] and [RFC3576].  See those documents for a
more detailed description.

The security mechanisms described in [RFC3579] and [RFC3576] are
focused on preventing an attacker from spoofing packets or modifying
packets in transit.  They do not prevent an authorized RADIUS
server or proxy from inserting attributes with malicious intent.

VLAN attributes sent by a RADIUS server or proxy may enable
access to unauthorized VLANs. These vulnerabilities can
be limited by performing authorization checks at the NAS.
For example, a NAS can be configured to accept only certain
VLANIDs from a given RADIUS server/proxy.

Similarly, an attacker gaining control of a RADIUS server or proxy
can modify the user priority table,
causing either degradation of quality of service (by downgrading user
priority of packets arriving at a port), or denial of service (by
raising the level of
priority of traffic at multiple ports of a device, oversubscribing the
switch or link capabilities)."

---------------------------------------------------------------------------------------
Issue 181: Review
Submitter name: Dan Romascanu
Submitter email address: [email-masked]
Date first submitted: March 16, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00311.html
Document: VLAN/Priority -00
Comment type: 'T'echnical
Priority: S
Section: Various
Rationale/Explanation of issue:

I believe that the document is in pretty good shape, I still have a few
comments which I believe are worth being considered.

Content:

1. [RFC2674] is now obsoleted by [RFC4363]. I suggest to modify this
reference.
2. The supplicant definition in 1.1 says:

          A supplicant is an entity that is being authenticated by an
          authenticator.  The supplicant may be connected to the
          authenticator at one end of a point-to-point LAN segment or
          802.11 wireless link.

It is not clear why 'point-to-point' is mentioned here seemingly as
opposed to wireless. I believe that the point that is being made is
about connecting to a point-to-point or shared LAN segment. I suggest to
replace this by:

          A supplicant is an entity that is being authenticated by an
          authenticator.  The supplicant may be connected to the
          authenticator at one end of a point-to-point or shared LAN
          segment

3. I believe that there is at least one other example of security attack
by insertion of attributes with a malicious content that is worth being
mentioned. This is the case when the user priority table is modified
causing either degradation of quality of service by downgrading user
priority of packets arriving at a port, or denial of service by
oversubscribing the switch or link capabilities by raising the level of
priority of traffic at multiple ports of a device.

Editorial:

1. It is recommended that abstract sections expand acronyms with the
exception of the obvious (IP, TCP, etc...). I would say that VLAN and
RADIUS are not in the obvious category.
2. NAS shows up first in section 1.3 and is not expanded.
3. The first phrase in Section 5 seems broken, I read it as the document
being vulnerable, which is not the intent, I believe.
[David Nelson]
That is a good point.  I think that further clarification would be
desirable, however.  My recollection of IEEE 802.1X is that it applies
to ports, which may be point-to-point LAN links, or virtual ports on
shared media defined by a protected association.

So perhaps we could extend the suggested text, as follows:

           A supplicant is an entity that is being authenticated by an
           authenticator.  The supplicant may be connected to the
           authenticator at one end of a point-to-point LAN link or via
           a protected association over a shared LAN segment.

--
to unsubscribe send a message 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, 16 Mar 2006 18:07:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 179: Editorial issue
Date: Thu, 16 Mar 2006 10:07:32 -0800

The text of issue 179 is enclosed below.  The proposed resolution is to 
accept the change.

-----------------------------------------------------------------------------------------
Issue 179: Editorial Issue
Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: March 14, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00279.html
Document: VLAN/Priority -00
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 1.3 Attribute Interpretation
Rationale/Explanation of issue: missing quote
Requested change:
s/value set to Unsupported Attribute" (401)/value set to "Unsupported
Attribute" (401)/

--
to unsubscribe send a message 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, 16 Mar 2006 18:06:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 178: Allowing Hints in Request Messages
Date: Thu, 16 Mar 2006 10:06:29 -0800

The text of Issue 178 is enclosed below.  The proposed resolution is to 
accept the changes.

--------------------------------------------------------------------------------------------------------------------------------
Issue 178: Allowing Hints in Request Messages
Submitter name: Mauricio Sanchez
Submitter email address: [email-masked]
Date first submitted: March 6, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00225.html
Document: draft-ietf-radext-vlan-00.txt
Comment type: T
Priority: 2
Section: Table in section 3, individual attributes
Rationale/Explanation of issue:
Draft-ietf-radext-vlan-00 does not allow
the new attributes to be sent in ACCESS-REQUEST messages.  If allowed,
attributes in the REQUEST message could serve as 'hints' to the RADIUS
server during the decision making process.
Requested change:  Allow attributes to be sent ACCESS-REQUEST message
Proposed changes to the document.

- Descriptions of individual attribute descriptions would be changed to
allow attributes in access request, as follows:
Multiple <attr_name> attributes MAY be included in an Access-Request,
Access-Accept or CoA-Request packet; this attribute MUST NOT be sent
within an Access-Challenge, Access-Reject, Disconnect-Request,
Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.

-Table in section 3 would be changed to:

   Access-   Access-  Access-  Access-    CoA-
   Request   Accept   Reject   Challenge  Req     #    Attribute
       0+      0+       0        0        0+    TBD  Egress-VLANID
       0-1     0-1      0        0        0-1   TBD  Ingress-Filters
       0+      0+       0        0        0+    TBD  Egress-VLAN-Name
       0-1     0-1      0        0        0-1   TBD  User-Priority-Table

--
to unsubscribe send 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: Thu, 16 Mar 2006 18:01:03 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 13:08:36 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
...

  I think we're agreeing on most things, and just nit-picking on
details.  That being said, let's continue.

> But alan, you cant go on the assumption that you will only accept
> non-binary "code" changes.

  I'm not assuming that.  I'm assuming that, again, for the 99% common
case, dictionary updates are enough to enable the server to deal with
new attributes.  This has been true in my experience, in the last
decade of working with RADIUS.

> Some attributes -- like the prepaid -- or mobile ip -- EAP --- require
> complex algorithms to be executed.  I doubt you can do them via
> configuraiton files.

  Which is why I never claimed you could.  Please, don't think I'm
unaware of algorithm changes that require updates to the server
binary.  I've mentioned that explicitely in previous messages.

> Yes. I agree. But my parser in my product is very capable and can handle
> more complex attribute structures then the other fellow.  So I can
> restate your statement as "complex things should be simle to do"

  If your parser can handle algorithm updates, too, more power to you.

  The problem the dictionaries solve is, again, the 99% common case
where a more complex parser just isn't necessary.

> Semantics are handled by clever policy files which use the attribute to
> compute some outcome.  The policy files are NOT standard in RADIUS.

  Agreed.  But again, the dictionaries (to a large extent) simplify
policy engines by removing the requirement that the policy engines
understand RADIUS attributes.  They don't.  They just understand name
to type mappings, and instances of named objects.

> The bottom line is this:
> We ought not make descision based on how complex or simple it is to
> handle an attribute.  That is nuts.

  I'm not sure why.  If an application can be supported by simply
defining a new attribute, and requiring that the attribute be sent in
a packet, then that application could be standardized with little
discussion.

  If an application requires more complex changes to the protocol,
then the decision to standardize it requires more discussion than the
previous case.

  Complexity *does* influence decisions.  Strongly.

> My original motivation for having a standard for complex attributes
> was because people were encoding attribute using name value pairs
> such as: in a String address="24 oberon",phone=" ".  I wanted to
> stop that because parsing these strings would slow every RADIUS
> server out there, and it was wasting space.

  Agreed completely.

> Also I resent somewhat the push now is so much that it ignores what we
> did a two years ago.  Based on discussion it was Jari who proposed
> encoding RADIUS attributes using Diameter syntax (I seem to recall that
> one of you guys were taking credit for that).

  Sorry for any conflict... that wasn't the intent.

> I think any other coding scheme is nuts and we should just move on with
> diameter encoding.  Unless of course  there is already working code as
> in the case of Prepaid.

  Agreed.  Let's move forward on that basis.

  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, 16 Mar 2006 17:45:24 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 12:47:17 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan,

See inline.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 2:04 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Avi Lior" <[email-masked]> wrote:
> > I know about policy files and GUIs and XmL and auto code etc...
>=20
>   Yes, I didn't mean to presume otherwise.  My point was that=20
> we should separate binary code changes from configuration file "code"
> changes.  Binary code changes may be complicated and=20
> expensive to deploy.  Configuration file changes can often be=20
> done by end users who know little about the protocol or=20
> implementation.

But alan, you cant go on the assumption that you will only accept
non-binary "code" changes.

Some attributes -- like the prepaid -- or mobile ip -- EAP --- require
complex algorithms to be executed.  I doubt you can do them via
configuraiton files.  Lets get real here.  What we are talking about is
adding a new Application to the AAA.

> > So whether I end up dealing with the attribute by pressing=20
> a few gui=20
> > buttons to add another If rule, or I have to insert a new=20
> EAP method=20
> > or Cryptography procedure do deal with the new attribute=20
> --- its all=20
> > code change.
>=20
>   That statement really masks the fact that some code changes=20
> are pretty trivial to do.  Adding new policies based on=20
> recently updated dictionary entries is usually pretty=20
> trivial.  Adding support for a new authentication algorithm=20
> is usually non-trivial.

Exactly.
=20
>   Dictionaries allow a much more common set of use-cases for "code"
> changes to be done trivially.  They follow the maxim of=20
> "simple things should be simple to do".

Yes. I agree. But my parser in my product is very capable and can handle
more complex attribute structures then the other fellow.  So I can
restate your statement as "complex things should be simle to do"
=20
> > In a very simple world yes you can live within the limits of your=20
> > dictionaries but in more complex scenarios, you  have to roll some=20
> > good old fashion  C compiler.
>=20
>   Agreed.  That's why I said the dictionaries catch the 99%=20
> common case, not 100% of the situations.

Lets be accurate here.  The dicitionary is about encoding and decoding
and very little about smeantics.

Semantics are handled by clever policy files which use the attribute to
compute some outcome.  The policy files are NOT standard in RADIUS.
Policy files are exectued by Policy Engines (which are NOT covered by
RADIUS).  Policy engines come in many flavours.  Some are simple and
some are complex.  For example, some may provide very simple parsing
capability and some support REGEX capabilities.  Some can execute script
code found in the policy file some can't.  Therefore "How far you can go
with your policy file -- depends on how much you were willing to invest
in your policy engine".

Where the policy engine stops is where you have to start adding code to
you RADIUS server.  In some cases adding code is expesive and in some
cases very simple.  It depends on how much you invested in you RADIUS
design.

The bottom line is this:
We ought not make descision based on how complex or simple it is to
handle an attribute.  That is nuts.

Rather we have to realize that RADIUS needs to support new Applications
with new attributes.  An entity that needs to use those attributes will
have to parse them.  Proxies that don't need to interact with them,
should be able to skip the attribute in the RADIUS packet.  This is done
by having the attributes hide within RADIUS "STRINGS".

Since the Application typically has to parse the attribute, it is not
necessary for the RADIUS dictionary driven code to be able to parse it.
RADIUS dictionaries don't need to parse the EAP-message.  We are all
comfortable with that.  Why are we worried about that now????

It would be nice though to have a standard way to encode complex
attributes.  But given that typically these complex attributes require
code beyond even the most complex policy engine then it is not necessary
to do so.

My original motivation for having a standard for complex attributes was
because people were encoding attribute using name value pairs such as:
in a String     address=3D"24 oberon",phone=3D"    ".  I wanted to stop =
that
because parsing these strings would slow every RADIUS server out there,
and it was wasting space.

Also I resent somewhat the push now is so much that it ignores what we
did a two years ago.  Based on discussion it was Jari who proposed
encoding RADIUS attributes using Diameter syntax (I seem to recall that
one of you guys were taking credit for that).

I think any other coding scheme is nuts and we should just move on with
diameter encoding.  Unless of course  there is already working code as
in the case of Prepaid.
=20
>   Alan DeKok.
>=20
>=20

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

Delivery-date: Thu, 16 Mar 2006 16:43:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 08:42:51 -0800

I have read the document, and am OK with it (other than the issues that have 
already been filed).

--
to unsubscribe send a message 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, 16 Mar 2006 15:52:07 +0000
Content-class: urn:content-classes:message
Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority  Draft
Date: Thu, 16 Mar 2006 10:51:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dan Romascanu writes...
=20
> It is not clear why 'point-to-point' is mentioned here seemingly as
> opposed to wireless. I believe that the point that is being made is
> about connecting to a point-to-point or shared LAN segment. I suggest
to
> replace this by:
>=20
>           A supplicant is an entity that is being authenticated by an
>           authenticator.  The supplicant may be connected to the
>           authenticator at one end of a point-to-point or shared LAN
>           segment

That is a good point.  I think that further clarification would be
desirable, however.  My recollection of IEEE 802.1X is that it applies
to ports, which may be point-to-point LAN links, or virtual ports on
shared media defined by a protected association.

So perhaps we could extend the suggested text, as follows:

           A supplicant is an entity that is being authenticated by an
           authenticator.  The supplicant may be connected to the
           authenticator at one end of a point-to-point LAN link or via
           a protected association over a shared LAN segment.

--
to unsubscribe send a message 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, 16 Mar 2006 11:59:29 +0000
content-class: urn:content-classes:message
Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft
Date: Thu, 16 Mar 2006 13:58:59 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I believe that the document is in pretty good shape, I still have a few
comments which I believe are worth being considered.=20

Content:

1. [RFC2674] is now obsoleted by [RFC4363]. I suggest to modify this
reference.=20
2. The supplicant definition in 1.1 says:=20

          A supplicant is an entity that is being authenticated by an
          authenticator.  The supplicant may be connected to the
          authenticator at one end of a point-to-point LAN segment or
          802.11 wireless link.

It is not clear why 'point-to-point' is mentioned here seemingly as
opposed to wireless. I believe that the point that is being made is
about connecting to a point-to-point or shared LAN segment. I suggest to
replace this by:

          A supplicant is an entity that is being authenticated by an
          authenticator.  The supplicant may be connected to the
          authenticator at one end of a point-to-point or shared LAN=20
          segment

3. I believe that there is at least one other example of security attack
by insertion of attributes with a malicious content that is worth being
mentioned. This is the case when the user priority table is modified
causing either degradation of quality of service by downgrading user
priority of packets arriving at a port, or denial of service by
oversubscribing the switch or link capabilities by raising the level of
priority of traffic at multiple ports of a device.=20

Editorial:

1. It is recommended that abstract sections expand acronyms with the
exception of the obvious (IP, TCP, etc...). I would say that VLAN and
RADIUS are not in the obvious category.
2. NAS shows up first in section 1.3 and is not expanded.=20
3. The first phrase in Section 5 seems broken, I read it as the document
being vulnerable, which is not the intent, I believe.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, March 14, 2006 5:30 PM
> To: [email-masked]
> Subject: PLEASE READ: RADEXT WG last call in progress on=20
> VLAN/Priority Draft
>=20
> There is a RADEXT WG last call in progress on the VLAN and=20
> Priority Attributes document, prior to sending it on to the=20
> IESG for consideration as a Proposed Standard.
>=20
> The document is available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt
>=20
> RADEXT WG last call will last until Friday, March 17, 2006.=20
> Please send your comments to the RADEXT WG mailing list=20
> ([email-masked]) in the format described on the RADEXT=20
> Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> NOTE: 5 reviews are required for the document to advance as a=20
> Proposed Standard.  If you have read the document, please=20
> post your opinion to the list, even if you have no issues to file:
>=20
> So far, only two reviews have been received:
> http://ops.ietf.org/lists/radiusext/2006/msg00169.html
> http://ops.ietf.org/lists/radiusext/2006/msg00225.html
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Thu, 16 Mar 2006 07:02:10 +0000
From: "Alan DeKok" <[email-masked]>
To: Barney Wolff <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 02:09:40 -0500
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> Why in the name of Turing do we agree to do this for managing our
> RADIUS entities but cannot or will not for the protocol itself?

  That's been the "holy grail" of many people for many years.
Unfortunately, the skills required involve a large subset of each of
coding, protocol design, algorithm analysis, language theory, etc.

  So far, it's been easier for protocol authors to hack something
together than to try to design such a system.  And the math people who
might be able to do it don't feel the pain, so they're not interested.

  Many code projects still use hand-written parsers (no, I don't mean
gcc), because for simple grammars, lexx & yacc are slower and more
complex than a few lines of simple string manipulation in C.

  The last company I worked at had something close to what you
describe.  Unfortunately, using it required that the customers spend
time learning how to use it, which turned out to be too high a hurdle
for many people, even if it did end up solving the problem better than
their existing tools.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 16 Mar 2006 06:56:27 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Thu, 16 Mar 2006 02:03:52 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> I know about policy files and GUIs and XmL and auto code etc...

  Yes, I didn't mean to presume otherwise.  My point was that we
should separate binary code changes from configuration file "code"
changes.  Binary code changes may be complicated and expensive to
deploy.  Configuration file changes can often be done by end users who
know little about the protocol or implementation.

> So whether I end up dealing with the attribute by pressing a few gui
> buttons to add another If rule, or I have to insert a new EAP method or
> Cryptography procedure do deal with the new attribute --- its all code
> change.

  That statement really masks the fact that some code changes are
pretty trivial to do.  Adding new policies based on recently updated
dictionary entries is usually pretty trivial.  Adding support for a
new authentication algorithm is usually non-trivial.

  Dictionaries allow a much more common set of use-cases for "code"
changes to be done trivially.  They follow the maxim of "simple things
should be simple to do".

> In a very simple world yes you can live within the limits of your
> dictionaries but in more complex scenarios, you  have to roll some good
> old fashion  C compiler.

  Agreed.  That's why I said the dictionaries catch the 99% common
case, not 100% of the situations.

  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, 16 Mar 2006 02:21:17 +0000
Date: Wed, 15 Mar 2006 21:21:02 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

On Wed, Mar 15, 2006 at 06:31:07PM -0500, Avi Lior wrote:
> 
> So whether or not the attribute is compound or not, if the server needs
> to "interact" with that attribute then it needs to have new code added.
> This applies to any server or client that needs to "interact" with that
> attribute.
> 
> So the notion of dictionary driven code and using existing radius types
> really speaks only about not adding any code to the RADIUS packet
> encoder/decoder. 

RADIUS entities do more than just "interact" with attributes.  They
also display them to humans, transfer them to other applications,
store them, validate them, and so on.  For many of these "peripheral"
purposes, something like a dictionary is helpful.

Of course, a sufficiently fancy dictionary can cope with packed data.
But why should it have to?  What is gained - a few bytes in a UDP
packet?  I am unable to imagine a scenario where the bandwidth sent
or received by a RADIUS entity is a significant issue, even for very
high volume applications.

In my ideal world, there would be an abstract data language akin
to ASN.1 (or ABNF) in which the set of attributes for some feature
could be represented, and there would be automated means to generate
code to handle encoding and decoding.  The abstract data type
definition would be included in the RFC defining the feature.  Why
in the name of Turing do we agree to do this for managing our RADIUS
entities but cannot or will not for the protocol itself?  That goes
double for Diameter.

Barney

--
to unsubscribe send a message 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, 16 Mar 2006 02:12:41 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Wed, 15 Mar 2006 21:14:29 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan

I know about policy files and GUIs and XmL and auto code etc... All of
those are code changes.  Its just different code.  Some code change is
simpler then others.

So whether I end up dealing with the attribute by pressing a few gui
buttons to add another If rule, or I have to insert a new EAP method or
Cryptography procedure do deal with the new attribute --- its all code
change. =20

Lets be real about it and not loose sight that when a server is required
to deal with a new attribute new code has to be inserted.

>   Dictionaries also allow the creation of complex policy=20
> languages, by separating the language syntax from the data=20
> and types the language operates on.

In a very simple world yes you can live within the limits of your
dictionaries but in more complex scenarios, you  have to roll some good
old fashion  C compiler. =20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Wednesday, March 15, 2006 6:47 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> "Avi Lior" <[email-masked]> wrote:
> > So whether or not the attribute is compound or not, if the server=20
> > needs to "interact" with that attribute then it needs to=20
> have new code added.
> > This applies to any server or client that needs to "interact" with=20
> > that attribute.
>=20
>   For clients, yes.  For servers, though, many have complex=20
> policy configuration files.  So the policy has to be updated=20
> to deal with a new attribute, but the server code does not=20
> need to change.
>=20
>   In many cases, the policy is GUI driven, and is "if you see=20
> FOO with value BAR in the request, respond with FOOD with value BARD".
>=20
> > So the notion of dictionary driven code and using existing radius=20
> > types really speaks only about not adding any code to the RADIUS=20
> > packet encoder/decoder.
>=20
>   Dictionaries also allow the creation of complex policy=20
> languages, by separating the language syntax from the data=20
> and types the language operates on.
>=20
>   Alan DeKok.
>=20

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

Envelope-to: [email-masked]
Delivery-date: Wed, 15 Mar 2006 23:39:43 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Wed, 15 Mar 2006 18:47:17 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> So whether or not the attribute is compound or not, if the server needs
> to "interact" with that attribute then it needs to have new code added.
> This applies to any server or client that needs to "interact" with that
> attribute.

  For clients, yes.  For servers, though, many have complex policy
configuration files.  So the policy has to be updated to deal with a
new attribute, but the server code does not need to change.

  In many cases, the policy is GUI driven, and is "if you see FOO with
value BAR in the request, respond with FOOD with value BARD".

> So the notion of dictionary driven code and using existing radius types
> really speaks only about not adding any code to the RADIUS packet
> encoder/decoder.

  Dictionaries also allow the creation of complex policy languages, by
separating the language syntax from the data and types the language
operates on.

  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, 15 Mar 2006 23:29:19 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Wed, 15 Mar 2006 18:31:07 -0500
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard,

I agree with what you wrote and I want to add something:

> As far as I can tell, while compound attributes have a rich=20
> history within RADIUS, being described in RFCs 2865, 2868,=20
> 2869, and 3162, at no point have any compound attributes been=20
> introduced which require individual addressing of=20
> sub-elements.  So as far as I can see, it is not use of=20
> "compound attributes" but rather "individually addressable=20
> sub-elements" that represents the critical distinction here.

But also, even if we added an attribute of known type say "FOO" type
integer, the Server would not have to add any code to parse this
attribute, but it probably will need to have code to handle this
attribute, unless of course all the server did was record the attribute
and did not intepret it.

So whether or not the attribute is compound or not, if the server needs
to "interact" with that attribute then it needs to have new code added.
This applies to any server or client that needs to "interact" with that
attribute.

So the notion of dictionary driven code and using existing radius types
really speaks only about not adding any code to the RADIUS packet
encoder/decoder.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, March 14, 2006 10:17 PM
> To: [email-masked]
> Subject: RE: New Technical Issues RE: WG last call in=20
> progress on VLAN/Priority Draft
>=20
> Glen Zorn said:
>=20
> "There are problems with such things, as this conversation=20
> illustrates.  One is that one person's "meaningful type" is=20
> another's "meaningless distinction", leading to (possibly=20
> endless) discussions akin to those medieval ones involving=20
> angels and pins ;-); another is the addition of yet another=20
> constituency to the debate over protocol extension.  How long=20
> would it be before we hear from some server vendor that some=20
> perfectly reasonable & extremely useful RADIUS extension=20
> cannot be adopted because "my parser won't handle that data type"?"
>=20
> Maybe it would be useful to go back to the original=20
> justification for the RADIUS dictionary.  RADIUS does not=20
> support explicit data typing as in ASN.1, for example.  As=20
> far as I can tell, the purpose of including any typing at all=20
> in RADIUS is to enable support for new attributes by addition=20
> of dictionary entries, without changing code.   This is not=20
> just an academic=20
> point about "data models" -- this has real impact on customers.
>=20
> As Emile has noted, some implementations have added support=20
> for more elaborate structures, allowing compound attributes=20
> of type "STRING" to be entered more easily (e.g. the tagged=20
> attributes of RFC 2868).
>=20
> However, this is but a detail -- using the basic RADIUS data=20
> types, it is possible for the administrator to add support=20
> for virtually any new attribute sent by the server to the=20
> client, by adding a dictionary entry. =20
> No new code required.  So if we are talking about attributes=20
> only sent in Access-Challenges or Access-Accepts, I don't=20
> think see how compound attributes affect the ability of=20
> administrators to add support for new attributes without code changes.
>=20
> The issue is really about attributes sent from the client to=20
> the server.  As Emile noted, if the attribute sub-elements=20
> don't need to be addressed individually, such as if they are=20
> always handled as an opaque blob, then the attribute can be=20
> treated as type "STRING" by the server, and existing=20
> implementations will work just fine, so there is no issue.
>=20
> The problem occurs if the sub-elements need to be referred to=20
> individually. =20
>   Can existing implementations handle this, or will new code=20
> be required? My guess is that in most cases, new code *will*=20
> be required.  If so, these kind of attributes represent a=20
> departure from the principles underlying the creation of the=20
> RADIUS dictionary, and will force users to upgrade their=20
> servers.  So this is really the situation in which compound=20
> attributes impose a real cost.
>=20
> As far as I can tell, while compound attributes have a rich=20
> history within RADIUS, being described in RFCs 2865, 2868,=20
> 2869, and 3162, at no point have any compound attributes been=20
> introduced which require individual addressing of=20
> sub-elements.  So as far as I can see, it is not use of=20
> "compound attributes" but rather "individually addressable=20
> sub-elements" that represents the critical distinction here.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 15 Mar 2006 18:31:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Attribute design thoughts (was RE: New Technical Issues RE: WG  last call in progress on VLAN/Priority Draft)
Date: Wed, 15 Mar 2006 12:56:55 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dan Romascanu writes...
=20
> The WG has already a number of RADIUS extensions documents in a more
> advance phase than the Design Guidelines.

Yes.  Although the Design Guidelines was originally one of the first
milestones in the WG charter, so this was not supposed to happen.

> Is the proposal to hold those waiting for the reference to review
> against, ...

We plan to stick to our current milestones.  If rough consensus is
achieved on the Design Guidelines, that should serve as the basis for
review for some of the later deliverables.  There is not plan to hold up
documents scheduled to be forwarded to the IESG prior to such a
consensus being formed on Design Guidelines.  Such documents are being
reviewed against past practice, and on an ad-hoc basis as to the current
thoughts of WG members on attribute design.

> ...or would these be treated as part of the already approved and try
to
> make the guidelines backwards compatible with them?

I suppose that factors into the consensus opinion.  It would seem
unfortunate to publish Proposed Standards RFCs that do not comport well
with the Design Guidelines BCP.  The timing is unfortunate, but we are
doing our best to manage to the current milestones.

> Moreover, does the WG considers this within the scope of the Design
> Guidelines document, or do we need more clarification or even an
extension=20
> of the charter?

I think it is understood to be within the scope of the Design Guidelines
document, as per the current charter.  If there is confusion as to the
purpose and scope of that document, comment from others within the WG
would be welcomed.

-- Dave

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

Delivery-date: Wed, 15 Mar 2006 17:01:00 +0000
content-class: urn:content-classes:message
Subject: RE: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)
Date: Wed, 15 Mar 2006 19:00:46 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Wednesday, March 15, 2006 6:18 PM
> To: [email-masked]
> Subject: Attribute design thoughts (was RE: New Technical=20
> Issues RE: WG last call in progress on VLAN/Priority Draft)
>=20
> Emile van Bergen writes...
>=20
> > It was half serious. What I'm after is to find out at which=20
> point you=20
> > would start to agree that certain things are better only taken
> together.
>=20
> OK. I was reacting to your phrasing "all kinds of bad, bad=20
> magic".  That doesn't move us forward, either.
>=20
> > We're having a theoretical debate, and you're not answering the=20
> > question. Let me try again. If RFC 2865 didn't have a time=20
> base type,=20
> > how would you propose a session time to be conveyed? As an=20
> attribute=20
> > consisting of subattributes allocated from a global IANA=20
> Type number=20
> > space, however wide?
>=20
> OK, theoretically speaking then.
>=20
> If there were no RADIUS time data type, then I would search=20
> to see if there were a standard one in common use, preferably=20
> one with a stable reference, e.g. an RFC.  I would almost=20
> certainly choose Unix Epoch time (seconds since January 1,=20
> 1970) which conveniently fits in an Integer.
> If I were worried about the 2024 (or whenever) wrap-around,=20
> I'd find another standard representation, and use that (maybe=20
> an unsigned long long, i.e. 64-bit integer).  If I were=20
> *forced* to use the representation you suggest, i.e. separate=20
> members of a structure for each of the "units" of time, and=20
> there were no existing standard I could reference, then I=20
> would look to the RADIUS Design Guidelines to see what is recommended.
>=20
> So, I haven't answered your question yet (but I will).  My=20
> point up to this juncture is that the WG should reach a=20
> consensus on design guidelines, and then each individual=20
> attribute design decision should be made with the benefit of=20
> those recommendations, providing a certain level of=20
> consistency.  This shouldn't be such an ad-hoc process, IMHO.
> I suppose this is a controversial opinion, something like=20
> advocating coding style standards.  :-)  While I have an=20
> opinion on this, I really don't care so much as to what the=20
> WG decides, as long as it comes to a consensus, and does so=20
> fairly quickly.  I would prefer that the guidelines are=20
> substantive, and provide some real guidance, rather than=20
> simply codifying the existing ad-hoc practices.
>=20
> OK, so we're in an imperfect world, and the WG has not yet=20
> come to consensus on design guidelines, so I'm left to my own=20
> devices.  How would I propose to encode the structure that=20
> you've presented as a hypothetical?  Toss a coin?  The=20
> problem is that in the absence of guidelines, it's a matter=20
> of personal style.
>=20
> How would I suggest that the design guidelines be worded to=20
> recommend encoding of structured data representations?  My=20
> suggestion would be to use the Extended RADIUS Attribute=20
> (however it is ultimately defined) and use whatever grouping=20
> (data aggregation) method it supports to structure the member=20
> elements into a logical structure.  This could be via=20
> sub-attributes, or via tagged attributes, or via grouped=20
> attributes (as in Diameter).
>=20
> I think it's important to reiterate some thoughts expressed=20
> elsewhere in this general discussion, however.  One of those=20
> concepts is the issue of whether or not a RADIUS Server or=20
> RADIUS Client needs to take an action that depends on the=20
> value of one or more individual members of a data structure. =20
> So far, much of this discussion has been from the view point=20
> of RADIUS Servers, in terms of data dictionary=20
> implementations.  We should also consider this from the NAS=20
> developer's viewpoint.
>=20
> If a RADIUS entity (Server or Client) needs to take some=20
> action dependent upon an element in a structure, it would be=20
> valuable and desirable to have the individual elements easily=20
> addressable.  Having sub-attribute IDs for these is one way,=20
> and in an Extended RADIUS Attribute we can define this scheme=20
> without incurring any backwards compatibility penalties.  We=20
> could also write custom string parser code for each=20
> individual attribute, which could work from fixed octet=20
> offsets, or could search for specified delimiter values in=20
> variable length fields.  I personally find this kind of code=20
> more cumbersome, less flexible, less re-usable, and more=20
> error prone.  It's certainly good job security for RADIUS=20
> developers.  :-)
>=20
> If no RADIUS entity needs to take action on the values of the=20
> structure elements, e.g. it is passed to another entity (such=20
> as EAP), or it is simply intended to be dumped verbatim into=20
> a RADIUS Accounting Server log file, then it can perfectly=20
> well be densely packed into a string.
> My only concern with this approach is that the author of a=20
> new attribute
> *claims* that it can be treated as a string, because it's=20
> never parsed, when in fact implementations of that=20
> application eventually *do* need to have access to the=20
> individual data elements, and thus end up parsing densely=20
> packed strings.
>=20
> Another way to look at this issue, purely for the sake of=20
> analysis, is to see how the same data items would be encoded=20
> in ASN.1, using SMIv2, for a MIB.  Pretend that we're using=20
> SNMP to provision the NAS instead of RADIUS.  How would you=20
> write the MIB?  You could easily see a relationship between=20
> leaf OIDs and RADIUS attributes (or sub-attributes).  Now=20
> before anyone starts the flames, I realize that RADIUS is not=20
> like SNMP.  For one thing RADIUS doesn't have a formal data=20
> model, like SNMP.  I think the exercise is potentially=20
> instructive, none the less.
>=20
> If the eventual consensus of the WG is that individually=20
> addressable elements of a structure are not our cup of tea=20
> for attribute encoding guidelines, and that we really want to=20
> formalize the custom octet packing method for attribute=20
> encoding, then I could live with that, if it were algorithmic=20
> and predictable, from one attribute to another.  One way to=20
> make such a scheme predictable would be to mimic the way a=20
> specified reference implementation of a C language complier,=20
> on a specified reference CPU architecture, would encode a C=20
> structure definition in physical memory, and simply clone=20
> that encoding method.
> One could handle the on-the-wire endian-ness with a simple=20
> mechanism such as the host-to-net and net-to-host macros=20
> (e.g. htonl, ntohl, etc).
>=20
> Any way we go, I'd *much* rather reach consensus on design=20
> guidelines and then be able to review proposed RADIUS=20
> extensions I-Ds against those concrete best current=20
> practices, rather than make ad-hoc evaluations of each new=20
> attribute against the personal opinions of the day.
>=20

The WG has already a number of RADIUS extensions documents in a more
advance phase than the Design Guidelines. Is the proposal to hold those
waiting for the reference to review against, or would these be treated
as part of the already approved and try to make the guidelines backwards
compatible with them? Moreover, does the WG considers thisa within the
scope of the Design Guidelines document, or do we need more
clarification or even an extension of the charter? =20

Dan

=20

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

Delivery-date: Wed, 15 Mar 2006 16:17:45 +0000
Content-class: urn:content-classes:message
Subject: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)
Date: Wed, 15 Mar 2006 11:17:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> It was half serious. What I'm after is to find out at which point you
> would start to agree that certain things are better only taken
together.

OK. I was reacting to your phrasing "all kinds of bad, bad magic".  That
doesn't move us forward, either.

> We're having a theoretical debate, and you're not answering the
> question. Let me try again. If RFC 2865 didn't have a time base type,
> how would you propose a session time to be conveyed? As an attribute
> consisting of subattributes allocated from a global IANA Type number
> space, however wide?

OK, theoretically speaking then.

If there were no RADIUS time data type, then I would search to see if
there were a standard one in common use, preferably one with a stable
reference, e.g. an RFC.  I would almost certainly choose Unix Epoch time
(seconds since January 1, 1970) which conveniently fits in an Integer.
If I were worried about the 2024 (or whenever) wrap-around, I'd find
another standard representation, and use that (maybe an unsigned long
long, i.e. 64-bit integer).  If I were *forced* to use the
representation you suggest, i.e. separate members of a structure for
each of the "units" of time, and there were no existing standard I could
reference, then I would look to the RADIUS Design Guidelines to see what
is recommended.

So, I haven't answered your question yet (but I will).  My point up to
this juncture is that the WG should reach a consensus on design
guidelines, and then each individual attribute design decision should be
made with the benefit of those recommendations, providing a certain
level of consistency.  This shouldn't be such an ad-hoc process, IMHO.
I suppose this is a controversial opinion, something like advocating
coding style standards.  :-)  While I have an opinion on this, I really
don't care so much as to what the WG decides, as long as it comes to a
consensus, and does so fairly quickly.  I would prefer that the
guidelines are substantive, and provide some real guidance, rather than
simply codifying the existing ad-hoc practices.

OK, so we're in an imperfect world, and the WG has not yet come to
consensus on design guidelines, so I'm left to my own devices.  How
would I propose to encode the structure that you've presented as a
hypothetical?  Toss a coin?  The problem is that in the absence of
guidelines, it's a matter of personal style.

How would I suggest that the design guidelines be worded to recommend
encoding of structured data representations?  My suggestion would be to
use the Extended RADIUS Attribute (however it is ultimately defined) and
use whatever grouping (data aggregation) method it supports to structure
the member elements into a logical structure.  This could be via
sub-attributes, or via tagged attributes, or via grouped attributes (as
in Diameter).

I think it's important to reiterate some thoughts expressed elsewhere in
this general discussion, however.  One of those concepts is the issue of
whether or not a RADIUS Server or RADIUS Client needs to take an action
that depends on the value of one or more individual members of a data
structure.  So far, much of this discussion has been from the view point
of RADIUS Servers, in terms of data dictionary implementations.  We
should also consider this from the NAS developer's viewpoint.

If a RADIUS entity (Server or Client) needs to take some action
dependent upon an element in a structure, it would be valuable and
desirable to have the individual elements easily addressable.  Having
sub-attribute IDs for these is one way, and in an Extended RADIUS
Attribute we can define this scheme without incurring any backwards
compatibility penalties.  We could also write custom string parser code
for each individual attribute, which could work from fixed octet
offsets, or could search for specified delimiter values in variable
length fields.  I personally find this kind of code more cumbersome,
less flexible, less re-usable, and more error prone.  It's certainly
good job security for RADIUS developers.  :-)

If no RADIUS entity needs to take action on the values of the structure
elements, e.g. it is passed to another entity (such as EAP), or it is
simply intended to be dumped verbatim into a RADIUS Accounting Server
log file, then it can perfectly well be densely packed into a string.
My only concern with this approach is that the author of a new attribute
*claims* that it can be treated as a string, because it's never parsed,
when in fact implementations of that application eventually *do* need to
have access to the individual data elements, and thus end up parsing
densely packed strings.

Another way to look at this issue, purely for the sake of analysis, is
to see how the same data items would be encoded in ASN.1, using SMIv2,
for a MIB.  Pretend that we're using SNMP to provision the NAS instead
of RADIUS.  How would you write the MIB?  You could easily see a
relationship between leaf OIDs and RADIUS attributes (or
sub-attributes).  Now before anyone starts the flames, I realize that
RADIUS is not like SNMP.  For one thing RADIUS doesn't have a formal
data model, like SNMP.  I think the exercise is potentially instructive,
none the less.

If the eventual consensus of the WG is that individually addressable
elements of a structure are not our cup of tea for attribute encoding
guidelines, and that we really want to formalize the custom octet
packing method for attribute encoding, then I could live with that, if
it were algorithmic and predictable, from one attribute to another.  One
way to make such a scheme predictable would be to mimic the way a
specified reference implementation of a C language complier, on a
specified reference CPU architecture, would encode a C structure
definition in physical memory, and simply clone that encoding method.
One could handle the on-the-wire endian-ness with a simple mechanism
such as the host-to-net and net-to-host macros (e.g. htonl, ntohl, etc).

Any way we go, I'd *much* rather reach consensus on design guidelines
and then be able to review proposed RADIUS extensions I-Ds against those
concrete best current practices, rather than make ad-hoc evaluations of
each new attribute against the personal opinions of the day.

--
to unsubscribe send a message 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, 15 Mar 2006 14:49:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: IETF last call comments on RADIUS Digest AWUthentcation
Date: Wed, 15 Mar 2006 06:49:32 -0800

---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 14:31:45 +0000
From: Alexey Melnikov <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
    [email-masked], [email-masked], [email-masked],
    [email-masked]
Subject: Re: AW: IETF last call comments on RADIUS Digest Authentication 
docum
           ent

Beck01, Wolfgang wrote:

>Alexey,
>
>my main focus for the -07 version was to address the 'discuss'
>points from the IESG site.
>
>
That is fine. I was under impression that all issues raised were addressed 
in
-07.

> > 1). [Major]: Everywhere in section 4: all references to "without quotes"
> > [..]
> > [Wolfgang]
> > > Blindly removing the surrounding quotes is exactly
> > what was meant. quoted-string is used to allow characters
> > that would break the HTTP syntax. This is not relevant for RADIUS, as we
> > have TLV. (Un-)Escaping the actual value would not save very much space
> > (I'd guess that escapes are rare) but complicate the implementation.
> > > [Alexey]
> > I think you are missing the point. Unescaping is not an optional HTTP
> > feature. An HTTP Digest username can contain "\" or <"> characters. They
> > must be escaped as per HTTP quoted string syntax. For example if you
> > have a username 'domain\user' it will be represented in HTTP Digest as
> > "domain\\user". If a naive implementation just strips the quotes it will
> > end up with 2 slashes and not 1, which will lead to digest verification
> > failure.
> > > Why do you think the RADIUS client should deal with escapes?
>It does not look into the values. That's the RADIUS server's
>task.
>
>
I guess you can do that. In which case you still have to say that Digest 
servers
MUST unescape values before processing them, as this is not obvious (I 
certainly
wouldn't have implemented this way).

> > This comment applies to at least to Digest-Username (section 4.13),
> > Digest-Realm (section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce
> > (section 4.11).
> > > 2). [Medium]: It would be nice to see examples of both scenario 1 and 
>2
> > in the
> > document. I think it will clean up a lot of confusion.
> > > [..]
>
>
> > [Alexey]
> > The message flow is fine, but there are so many optional RADIUS options
> > that a regular reader will be easily lost. An additional example can
> > also help verify that your description is actually correct. I had to
> > reread section 3.1 multiple times to understand how it relates to the
> > two scenarios.
> > > > I've split up the larger text blocks into sections to make it easier
>to follow.
>
>
I've seen this change and it improved the readability, thank you. But I 
still
want another example ;-).

> > 3). [Minor]
> > > 3.2.5.  Obtaining Nonces
> > > > > The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
> > > Realm, Digest-Domain and Digest-Opaque attributes in the Access-
> > > Challenge carrying the nonce.  If these attributes are > present, the
> > > client MUST use them.
> > > The Digest-Realm attribute is required as per section 3.2. The use of
> > "can" is confusing in this case, as all other attributes are optional.
> > > I can't find the quoted section in -07. The closest match is:
>"The RADIUS server can send Digest-Qop, Digest-
>Algorithm, Digest-Domain and Digest-Opaque attributes in the Access-
>Challenge carrying the nonce.  If these attributes are present, the
>client MUST use them."
>
Ok. The original issue seemed to be addressed.

> > 4). [Medium]
> > > > 3.2.  RADIUS Server Behavior
> > [...]
> > > A RADIUS server MUST check if the RADIUS client is authorized to
> > > serve users of the realm mentioned in the Digest-Realm > attribute.  
>If
> > > the RADIUS client is not authorized, the RADIUS server > MUST send an
> > > Access-Reject.  The RADIUS server SHOULD log the event so as to
> > > notify the operator, and MAY take additional action such > as sending
> > > an Access-Reject in response to all future requests from > this 
>client,
> > > until this behavior is reset by management action.
> > > If the server follow the last MAY, this can be used by DOS attacks, so 
>I
> > think this should be pointed out.
> > > [Wolfgang]
> > > In this paragraph or in the Security Considerations section?
> > > [Alexey]
> > In this section.
> > > Not following the MAY might result in cracked passwords...
>
>
There is a tradeoff, IMHO, the document should explain both problems with
following and not following MAY. This would be much better than just 
explaining
one side.

> > 5). [Medium]
> > > 4.4.  Digest-Response-Auth attribute
> > > > > Description
> > > This attribute enables the RADIUS server to prove > possession of
> > > the password.  If the previously received > Digest-Qop attribute
> > > was 'auth-int' (without quotes), the RADIUS server > MUST send a
> > > Digest-HA1 attribute instead of a Digest-Response-Auth
> > > attribute.
> > > This MUST is confusing, as other sections say that both
> > Digest-Response-Auth and Digest-HA1 are optional.
> > > [Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if
> > Digest-Qop was
> > auth-int.
> > > [Alexey]
> > The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that
> > Digest-HA1 is truly
> > optional:
> > o  If the Access-Accept packet contains neither a Digest-Response-
> >      Auth nor a Digest-HA1 attribute, the RADIUS client will not create
> > an Authentication-Info header for its HTTP-style response.
> > > <<Not addressed. Suggestion how to address the issue:
> > If the previously received Digest-Qop attribute
> > was 'auth-int' (without surrounding quotes), the > RADIUS server
> >         MUST NOT send a Digest-Response-Auth attribute and SHOULD send
> > a Digest-HA1 attribute instead (see section 4.19).
> > > We have discussed that before. How do you express 'A MUST be sent if
>conditions C holds, and MAY be sent if condition C doesn't hold.'?
>
>
The best I can see is to use conditional "if C, then MAY ..., else MUST 
...".

I suggested specific text above, do you think it is wrong?

>Is A mandatory? Is A optional?
>
>
> > 6). [Medium]
> > > > 4.8.  Digest-Qop attribute
> > > > > Description
> > > This attribute holds the Quality of Protection > parameter that
> > > influences the HTTP Digest calculation.  This > attribute MUST
> > > only be used in Access-Request and > Access-Challenge packets.  A
> > > RADIUS client SHOULD insert one of the Digest-Qop > attributes it
> > > has received in a previous Access-Challenge packet.
> > > I was under impression that the HTTP[-like] client is the one choosing
> > Qop from the list of Qops specified by the RADIUS server.
> > > The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop
> > attributes it has received in a previous Access-Challenge packet."
> > implies that the RADIUS client (== HTTP server) is the one picking the
> > Qop. I think the last sentence should be reworded to say something like
> > this:
> > > "A RADIUS client sends the Qop value received from the HTTP client in
> > the Digest-Qop attribute."
> > > See the 'Text' paragraph of the section.
>
>
I will get back to you on this one.

> > 7). [Medium]
> > > > RADIUS
> > > servers SHOULD insert at least one Digest-Qop > attribute in an
> > > Access-Challenge packet.  Digest-Qop is optional > in order to
> > > preserve backward compatibility with a minimal > implementation
> > >      of [RFC2069].
> > > Type
> > >      [IANA: use 109 if possible] for Digest-Qop
> > > Length
> > > > =3
> > > Text
> > > In Access-Requests, the RADIUS client takes the > value of the
> > > qop directive (qop-value as described in > [RFC2617]) without the
> > > quotes from the HTTP-style request it wants to > authenticate.
> > > In Access-Challenge packets, the RADIUS server > puts a desired
> > > qop-value into this attribute.  If the RADIUS > server supports
> > > more than one "quality of protection" value, it > puts each qop-
> > > value into a separate Digest-Qop attribute.
> > > As per my comment above - if multiple Qop values were specified by the
> > RADIUS server, the RADIUS client needs to put them into a single "qop"
> > directive containing comma separated list of Qop values.
> > > [Wolfgang] This is one possibility. I've chosen a different one:
> > > "If the RADIUS server supports more than one "quality of protection"
> > value, it puts each qop-value into a separate Digest-Qop attribute." Do
> > you object to splitting up the qop directive into various TLVs?
> > > [Alexey]
> > I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is
> > backward compatible with HTTP Digest) implementations. The problem is
> > that the behavior you propose was never explicitly allowed or disallowed
> > in the HTTP Digest document.
> > > <<Suggestions how to address: either say that all qop values are sent 
>in
> > a single HTTP Digest qop directive, or add a note explaining possible
> > interoperability issue if this is not done.>>
> > > A RADIUS attribute consisting of a list of items would be a structured
>attribute.
>The use of structured attributes is >>highly<< controversial in the WG.
>I dont see a problem with existing implementations. The server has to parse
>the RADIUS message anyway. If you have a RfC 2617 lib, just concat the
>attributes
>to form a comma-separated list.
>
>
I am not saying that doing one way or another is *difficult*. I am just 
pointing
out that there are existing implementations which can't cope with
"qop=foo,qop=bar". They will either treat it is an error, or ignore all but 
the
last value.

> > 8). [Minor]
> > > > 4.13.  Digest-Username attribute
> > > > > Description
> > > This attribute holds the user name used in the HTTP digest
> > > calculation.  The RADIUS server MUST use this > attribute only
> > > for the purposes of calculating the digest.  In order to
> > > determine the appropriate user credentials, the > RADIUS server
> > > MUST use the User-Name (1) attribute, and MUST NOT use the
> > > Digest-Username attribute.  This attribute MUST > only be used in
> > > Access-Request packets.
> > > I am still not convinced that the Digest-Username is ever different 
>from
> > the User-Name attribute. I would like to see an example when they would
> > be different.
> > [Wolfgang]
> > > What if your current policy was to assign HTTP user names containing 
>'@'
> > signs? A RADIUS infrastructure would interpret those User-Names as NAIs
> > which may lead to undesired effects.
> > > [Alexey]
> > I think giving this example in the document would explain why they may
> > be different.
> > >
There are two attributes with nearly identical meaning. The document doesn't
explain why both ot them are needed. An example you've mentioned will 
explain
why both are needed.

> > You also need to add some text explaining how User-Name can be derived
> > from the Digest-Username.
> > > Implementers of the original draft-sterman didn't seem to have that
>problem.
>
>
Sorry, this doesn't prove anything.

Regards,
Alexey

--
to unsubscribe send a message 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, 15 Mar 2006 14:49:10 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: IETF  last call comments on RADIUS Digest Authentication document
Date: Wed, 15 Mar 2006 06:48:49 -0800

---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 15:02:28 +0100
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
    [email-masked], [email-masked], [email-masked]
Subject: AW: IETF last call comments on RADIUS Digest Authentication 
document

Alexey,

my main focus for the -07 version was to address the 'discuss'
points from the IESG site.

>1). [Major]: Everywhere in section 4: all references to "without quotes" 
>[..]
>[Wolfgang]
>
>Blindly removing the surrounding quotes is exactly
>what was meant. quoted-string is used to allow characters
>that would break the HTTP syntax. This is not relevant for RADIUS, as we 
>have TLV. (Un-)Escaping the actual value would not save very much space 
>(I'd guess that escapes are rare) but complicate the implementation.
>
>[Alexey]
>I think you are missing the point. Unescaping is not an optional HTTP 
>feature. An HTTP Digest username can contain "\" or <"> characters. They 
>must be escaped as per HTTP quoted string syntax. For example if you have a 
>username 'domain\user' it will be represented in HTTP Digest as 
>"domain\\user". If a naive implementation just strips the quotes it will 
>end up with 2 slashes and not 1, which will lead to digest verification 
>failure.
Why do you think the RADIUS client should deal with escapes?
It does not look into the values. That's the RADIUS server's
task.

>This comment applies to at least to Digest-Username (section 4.13), 
>Digest-Realm (section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce 
>(section 4.11).
>
>2). [Medium]: It would be nice to see examples of both scenario 1 and 2 in 
>the
>document. I think it will clean up a lot of confusion.
>
[..]
>[Alexey]
>The message flow is fine, but there are so many optional RADIUS options 
>that a regular reader will be easily lost. An additional example can also 
>help verify that your description is actually correct. I had to reread 
>section 3.1 multiple times to understand how it relates to the two 
>scenarios.
>
I've split up the larger text blocks into sections to make it easier
to follow.

>3). [Minor]
>  >3.2.5.  Obtaining Nonces
>  >
>  >   The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
>  >   Realm, Digest-Domain and Digest-Opaque attributes in the Access-
>  >   Challenge carrying the nonce.  If these attributes are present, the
>  >   client MUST use them.
>
>The Digest-Realm attribute is required as per section 3.2. The use of "can" 
>is confusing in this case, as all other attributes are optional.
I can't find the quoted section in -07. The closest match is:
"The RADIUS server can send Digest-Qop, Digest-
   Algorithm, Digest-Domain and Digest-Opaque attributes in the Access-
   Challenge carrying the nonce.  If these attributes are present, the
   client MUST use them."

>4). [Medium]
>
>  >3.2.  RADIUS Server Behavior
>[...]
>  >   A RADIUS server MUST check if the RADIUS client is authorized to
>  >   serve users of the realm mentioned in the Digest-Realm attribute.  If
>  >   the RADIUS client is not authorized, the RADIUS server MUST send an
>  >   Access-Reject.  The RADIUS server SHOULD log the event so as to
>  >   notify the operator, and MAY take additional action such as sending
>  >   an Access-Reject in response to all future requests from this client,
>  >   until this behavior is reset by management action.
>
>If the server follow the last MAY, this can be used by DOS attacks, so I 
>think this should be pointed out.
>
>[Wolfgang]
>
>In this paragraph or in the Security Considerations section?
>
>[Alexey]
>In this section.
>
Not following the MAY might result in cracked passwords...

>5). [Medium]
>  >4.4.  Digest-Response-Auth attribute
>  >
>  >   Description
>  >         This attribute enables the RADIUS server to prove possession of
>  >         the password.  If the previously received Digest-Qop attribute
>  >         was 'auth-int' (without quotes), the RADIUS server MUST send a
>  >         Digest-HA1 attribute instead of a Digest-Response-Auth
>  >         attribute.
>
>This MUST is confusing, as other sections say that both 
>Digest-Response-Auth and Digest-HA1 are optional.
>
>[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if 
>Digest-Qop was
>auth-int.
>
>[Alexey]
>The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that 
>Digest-HA1 is truly
>optional:
>    o  If the Access-Accept packet contains neither a Digest-Response-
>       Auth nor a Digest-HA1 attribute, the RADIUS client will not create
>       an Authentication-Info header for its HTTP-style response.
>
><<Not addressed. Suggestion how to address the issue:
>          If the previously received Digest-Qop attribute
>          was 'auth-int' (without surrounding quotes), the RADIUS server
>          MUST NOT send a Digest-Response-Auth attribute and SHOULD send
>          a Digest-HA1 attribute instead (see section 4.19).
>
We have discussed that before. How do you express 'A MUST be sent if
conditions C holds, and MAY be sent if condition C doesn't hold.'?
Is A mandatory? Is A optional?
>
>6). [Medium]
>
>  >4.8.  Digest-Qop attribute
>  >
>  >   Description
>  >         This attribute holds the Quality of Protection parameter that
>  >         influences the HTTP Digest calculation.  This attribute MUST
>  >         only be used in Access-Request and Access-Challenge packets.  A
>  >         RADIUS client SHOULD insert one of the Digest-Qop attributes it
>  >         has received in a previous Access-Challenge packet.
>
>I was under impression that the HTTP[-like] client is the one choosing Qop 
>from the list of Qops specified by the RADIUS server.
>
>The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop 
>attributes it has received in a previous Access-Challenge packet." implies 
>that the RADIUS client (== HTTP server) is the one picking the Qop. I think 
>the last sentence should be reworded to say something like this:
>
>"A RADIUS client sends the Qop value received from the HTTP client in the 
>Digest-Qop attribute."
See the 'Text' paragraph of the section.

>
>7). [Medium]
>
>  >RADIUS
>  >         servers SHOULD insert at least one Digest-Qop attribute in an
>  >         Access-Challenge packet.  Digest-Qop is optional in order to
>  >         preserve backward compatibility with a minimal implementation
>  >         of [RFC2069].
>  >   Type
>  >         [IANA: use 109 if possible] for Digest-Qop
>  >   Length
>  >         >=3
>  >   Text
>  >         In Access-Requests, the RADIUS client takes the value of the
>  >         qop directive (qop-value as described in [RFC2617]) without the
>  >         quotes from the HTTP-style request it wants to authenticate.
>  >         In Access-Challenge packets, the RADIUS server puts a desired
>  >         qop-value into this attribute.  If the RADIUS server supports
>  >         more than one "quality of protection" value, it puts each qop-
>  >         value into a separate Digest-Qop attribute.
>
>As per my comment above - if multiple Qop values were specified by the 
>RADIUS server, the RADIUS client needs to put them into a single "qop" 
>directive containing comma separated list of Qop values.
>
>[Wolfgang] This is one possibility. I've chosen a different one:
>
>"If the RADIUS server supports more than one "quality of protection" value, 
>it puts each qop-value into a separate Digest-Qop attribute." Do you object 
>to splitting up the qop directive into various TLVs?
>
>[Alexey]
>I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is 
>backward compatible with HTTP Digest) implementations. The problem is that 
>the behavior you propose was never explicitly allowed or disallowed in the 
>HTTP Digest document.
>
>  <<Suggestions how to address: either say that all qop values are sent in 
>a single HTTP Digest qop directive, or add a note explaining possible 
>interoperability issue if this is not done.>>
A RADIUS attribute consisting of a list of items would be a structured
attribute.
The use of structured attributes is >>highly<< controversial in the WG.
I dont see a problem with existing implementations. The server has to parse
the RADIUS message anyway. If you have a RfC 2617 lib, just concat the
attributes
to form a comma-separated list.

>
>8). [Minor]
>
>  >4.13.  Digest-Username attribute
>  >
>  >   Description
>  >         This attribute holds the user name used in the HTTP digest
>  >         calculation.  The RADIUS server MUST use this attribute only
>  >         for the purposes of calculating the digest.  In order to
>  >         determine the appropriate user credentials, the RADIUS server
>  >         MUST use the User-Name (1) attribute, and MUST NOT use the
>  >         Digest-Username attribute.  This attribute MUST only be used in
>  >         Access-Request packets.
>
>I am still not convinced that the Digest-Username is ever different from 
>the User-Name attribute. I would like to see an example when they would be 
>different.
>[Wolfgang]
>
>What if your current policy was to assign HTTP user names containing '@' 
>signs? A RADIUS infrastructure would interpret those User-Names as NAIs 
>which may lead to undesired effects.
>
>[Alexey]
>I think giving this example in the document would explain why they may be 
>different.
>
>You also need to add some text explaining how User-Name can be derived from 
>the Digest-Username.
Implementers of the original draft-sterman didn't seem to have that
problem.

Thanks for your efforts,

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany

--
to unsubscribe send a message 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, 15 Mar 2006 14:40:10 +0000
Date: Wed, 15 Mar 2006 15:39:40 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 14, 2006 at 05:33:48PM -0500, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > Eg. the number of hours, minutes and seconds that a session lasted are
> > so closely related that we decided to do all kinds of bad, bad magic
> > to those 3 values and pack them together into one attribute:
> > Acct-Session-Time.
> 
> I think perhaps you are making a jest at my expense.  That's fine; I
> have a thick skin.

It was half serious. What I'm after is to find out at which point you
would start to agree that certain things are better only taken together.

My small joke at your expense attempted to gauge how far we need to go
before reaching common ground, but you sadly, you rejected my attempt.

> > If all packing is bad, I suppose you also consider /that/ attribute a
> > candidate for a complex data type as well? No? 
> 
> No.
> 
> > Why not?
> 
> Because RFC 2865 defines a time as a base data type:

We're having a theoretical debate, and you're not answering the
question. Let me try again. If RFC 2865 didn't have a time base type,
how would you propose a session time to be conveyed? As an attribute
consisting of subattributes allocated from a global IANA Type number
space, however wide?

No? Why not?

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Envelope-to: [email-masked]
Delivery-date: Wed, 15 Mar 2006 06:07:35 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Wed, 15 Mar 2006 01:14:47 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> As far as I can tell, the purpose of including any typing at all in
> RADIUS is to enable support for new attributes by addition of
> dictionary entries, without changing code.  This is not just an
> academic point about "data models" -- this has real impact on
> customers.

  Yes.  The other side of this requirement is that new functionality
that requires *interpretation* of the attribute content may require
new types in the dictionary.  This hasn't historically been a problem
for implementors.

  That is, the dictionaries exist to solve the 99% common problem,
where vendors need to send a string/integer/ipaddr in RADIUS to their
box.  Server vendors then can update dictionaries without changing
server code.

  In this model, the VLAN format fits just fine.  It's an ASCII string
with magic format.  That's no different than other magically formatted
text strings like in RFC 2865:

5.22.  Framed-Route
...
      That is followed by a space, a gateway address in dotted quad
      form, a space, and one or more metrics separated by spaces.  For
      example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400".
...

  There may be others, but that's the first one that springs to mind.
Multi-field text strings are well within common RADIUS practices.

> The issue is really about attributes sent from the client to the server.  As 
> Emile noted, if the attribute sub-elements don't need to be addressed 
> individually, such as if they are always handled as an opaque blob, then the 
> attribute can be treated as type "STRING" by the server, and existing 
> implementations will work just fine, so there is no issue.

  I concur.

> As far as I can tell, while compound attributes have a rich history within 
> RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have 
> any compound attributes been introduced which require individual addressing 
> of sub-elements.  So as far as I can see, it is not use of "compound 
> attributes" but rather "individually addressable sub-elements" that 
> represents the critical distinction here.

  That's a good summary.

  For this draft, the semantics of the attribute would not change if
the document was updated to make it an attribute of type "text"
containing no embedded fields.  The description text could then add
that the format had special requirements: the VLAN name should be
prefixed with an ASCII "1" or "2".

  If we go down that route, I would *then* say that there should be a
space between the two fields, just to address human issues.
Administrators can readily interpret multi-field text strings, if the
fields are separated by spaces.  As the document exists today, there
are human interpretation issues, as was earlier pointed out.

  Still, I'm OK with it as it is.  I had no objections during the whol
review process, so it would be a little inopportune to comment now.

  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, 15 Mar 2006 03:17:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Tue, 14 Mar 2006 19:17:07 -0800

Glen Zorn said:

"There are problems with such things, as this conversation illustrates.  One 
is that one person's "meaningful type" is another's "meaningless 
distinction", leading to (possibly endless) discussions akin to those 
medieval ones involving angels and pins ;-); another is the addition of yet 
another constituency to the debate over protocol extension.  How long would 
it be before we hear from some server vendor that some perfectly reasonable 
& extremely useful RADIUS extension cannot be adopted because "my parser 
won't handle that data type"?"

Maybe it would be useful to go back to the original justification for the 
RADIUS dictionary.  RADIUS does not support explicit data typing as in 
ASN.1, for example.  As far as I can tell, the purpose of including any 
typing at all in RADIUS is to enable support for new attributes by addition 
of dictionary entries, without changing code.   This is not just an academic 
point about "data models" -- this has real impact on customers.

As Emile has noted, some implementations have added support for more 
elaborate structures, allowing compound attributes of type "STRING" to be 
entered more easily (e.g. the tagged attributes of RFC 2868).

However, this is but a detail -- using the basic RADIUS data types, it is 
possible for the administrator to add support for virtually any new 
attribute sent by the server to the client, by adding a dictionary entry.  
No new code required.  So if we are talking about attributes only sent in 
Access-Challenges or Access-Accepts, I don't think see how compound 
attributes affect the ability of administrators to add support for new 
attributes without code changes.

The issue is really about attributes sent from the client to the server.  As 
Emile noted, if the attribute sub-elements don't need to be addressed 
individually, such as if they are always handled as an opaque blob, then the 
attribute can be treated as type "STRING" by the server, and existing 
implementations will work just fine, so there is no issue.

The problem occurs if the sub-elements need to be referred to individually.  
  Can existing implementations handle this, or will new code be required? My 
guess is that in most cases, new code *will* be required.  If so, these kind 
of attributes represent a departure from the principles underlying the 
creation of the RADIUS dictionary, and will force users to upgrade their 
servers.  So this is really the situation in which compound attributes 
impose a real cost.

As far as I can tell, while compound attributes have a rich history within 
RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have 
any compound attributes been introduced which require individual addressing 
of sub-elements.  So as far as I can see, it is not use of "compound 
attributes" but rather "individually addressable sub-elements" that 
represents the critical distinction here.

--
to unsubscribe send a message 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, 15 Mar 2006 02:48:45 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF last call comments on RADIUS Digest Authentication document not addressed
Date: Tue, 14 Mar 2006 18:48:11 -0800

>---------- Forwarded message ----------
>Date: Wed, 15 Mar 2006 02:26:43 +0000
>From: Alexey Melnikov <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked]
Subject: Re: IETF last call comments on RADIUS Digest Authentication 
document

I've just checked the updated document and about half of the issues I've

I've reduced my original comments to the following list (Note, even though
some of the comments are minor, I would like to at least hear back some 
argument
from authors on why they would not be addressed. My new comments are 
enclosed in
<<>>):

1). [Major]: Everywhere in section 4: all references to "without quotes" has 
to
be replaced with "unquoted" or similar. "Without quotes" can be
interpreted as just blindly removing the surrounding quote characters,
however many attribute values are allowed to contain quoted (escaped)
"\" and <">, so just removing the quotes will not produce proper result.

>[Wolfgang]
>
>Blindly removing the surrounding quotes is exactly
>what was meant. quoted-string is used to allow characters
>that would break the HTTP syntax. This is not relevant for RADIUS,
>as we have TLV. (Un-)Escaping the actual value would not save very
>much space (I'd guess that escapes are rare) but complicate the
>implementation.

[Alexey]
I think you are missing the point. Unescaping is not an optional HTTP
feature. An HTTP Digest username can contain "\" or <"> characters. They
must be escaped as per HTTP quoted string syntax. For example if you
have a username 'domain\user' it will be represented in HTTP Digest as
"domain\\user". If a naive implementation just strips the quotes it will
end up with 2 slashes and not 1, which will lead to digest verification
failure.

This comment applies to at least to Digest-Username (section 4.13), 
Digest-Realm
(section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce (section 4.11).

2). [Medium]: It would be nice to see examples of both scenario 1 and 2 in 
the
document. I think it will clean up a lot of confusion.

>[Wolfgang]
>
>What's wrong with message flow given in 1.3.1 figure 2?
>
[Alexey]
The message flow is fine, but there are so many optional RADIUS options
that a regular reader will be easily lost. An additional example can
also help verify that your description is actually correct. I had to
reread section 3.1 multiple times to understand how it relates to the
two scenarios.

3). [Minor]
>3.2.5.  Obtaining Nonces
>
>The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
>Realm, Digest-Domain and Digest-Opaque attributes in the Access-
>Challenge carrying the nonce.  If these attributes are present, the
>client MUST use them.

The Digest-Realm attribute is required as per section 3.2. The use of
"can" is confusing in this case, as all other attributes are optional.

4). [Medium]

>3.2.  RADIUS Server Behavior
>[...]
>A RADIUS server MUST check if the RADIUS client is authorized to
>serve users of the realm mentioned in the Digest-Realm attribute.  If
>the RADIUS client is not authorized, the RADIUS server MUST send an
>Access-Reject.  The RADIUS server SHOULD log the event so as to
>notify the operator, and MAY take additional action such as sending
>an Access-Reject in response to all future requests from this client,
>until this behavior is reset by management action.

If the server follow the last MAY, this can be used by DOS attacks, so I
think this should be pointed out.

>[Wolfgang]
>
>In this paragraph or in the Security Considerations section?

[Alexey]
In this section.

5). [Medium]

>4.4.  Digest-Response-Auth attribute
>
>Description
>This attribute enables the RADIUS server to prove possession of
>the password.  If the previously received Digest-Qop attribute
>was 'auth-int' (without quotes), the RADIUS server MUST send a
>Digest-HA1 attribute instead of a Digest-Response-Auth
>attribute.

This MUST is confusing, as other sections say that both
Digest-Response-Auth and Digest-HA1 are optional.

>[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if 
>Digest-Qop
>was auth-int.

[Alexey]
The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that
Digest-HA1 is truly optional:
o  If the Access-Accept packet contains neither a Digest-Response-
Auth nor a Digest-HA1 attribute, the RADIUS client will not create
an Authentication-Info header for its HTTP-style response.

<<Not addressed. Suggestion how to address the issue:
If the previously received Digest-Qop attribute
was 'auth-int' (without surrounding quotes), the RADIUS server
MUST NOT send a Digest-Response-Auth attribute and SHOULD send
a Digest-HA1 attribute instead (see section 4.19).

6). [Medium]

>4.8.  Digest-Qop attribute
>
>Description
>This attribute holds the Quality of Protection parameter that
>influences the HTTP Digest calculation.  This attribute MUST
>only be used in Access-Request and Access-Challenge packets.  A
>RADIUS client SHOULD insert one of the Digest-Qop attributes it
>has received in a previous Access-Challenge packet.

I was under impression that the HTTP[-like] client is the one choosing
Qop from the list of Qops specified by the RADIUS server.

The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop
attributes it has received in a previous Access-Challenge packet."
implies that the RADIUS client (== HTTP server) is the one picking the
Qop. I think the last sentence should be reworded to say something like 
this:

"A RADIUS client sends the Qop value received from the HTTP client in the
Digest-Qop attribute."

7). [Medium]

>RADIUS
>servers SHOULD insert at least one Digest-Qop attribute in an
>Access-Challenge packet.  Digest-Qop is optional in order to
>preserve backward compatibility with a minimal implementation
>of [RFC2069].
>Type
>      [IANA: use 109 if possible] for Digest-Qop
>Length
> > =3
>Text
>In Access-Requests, the RADIUS client takes the value of the
>qop directive (qop-value as described in [RFC2617]) without the
>quotes from the HTTP-style request it wants to authenticate.
>In Access-Challenge packets, the RADIUS server puts a desired
>qop-value into this attribute.  If the RADIUS server supports
>more than one "quality of protection" value, it puts each qop-
>value into a separate Digest-Qop attribute.

As per my comment above - if multiple Qop values were specified by the
RADIUS server, the RADIUS client needs to put them into a single "qop"
directive containing comma separated list of Qop values.

>[Wolfgang] This is one possibility. I've chosen a different one:
>
>"If the RADIUS server supports more than one "quality of protection" value, 
>it
>puts each qop-value into a separate Digest-Qop attribute."
>Do you object to splitting up the qop directive into various TLVs?
>
[Alexey]
I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is
backward compatible with HTTP Digest) implementations.
The problem is that the behavior you propose was never explicitly
allowed or disallowed in the HTTP Digest document.

<<Suggestions how to address: either say that all qop values are sent in a
single HTTP Digest qop directive, or add a note explaining possible
interoperability issue if this is not done.>>

8). [Minor]
>
>4.13.  Digest-Username attribute
>
>Description
>This attribute holds the user name used in the HTTP digest
>calculation.  The RADIUS server MUST use this attribute only
>for the purposes of calculating the digest.  In order to
>determine the appropriate user credentials, the RADIUS server
>MUST use the User-Name (1) attribute, and MUST NOT use the
>Digest-Username attribute.  This attribute MUST only be used in
>Access-Request packets.

I am still not convinced that the Digest-Username is ever different from
the User-Name attribute. I would like to see an example when they would
be different.

>[Wolfgang]
>
>What if your current policy was to assign HTTP user names containing '@'
>signs? A RADIUS infrastructure would interpret those User-Names as NAIs
>which may lead to undesired effects.
>
[Alexey]
I think giving this example in the document would explain why they may
be different.

You also need to add some text explaining how User-Name can be derived
from the Digest-Username.

===
Regards,
Alexey

--
to unsubscribe send a message 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, 14 Mar 2006 23:47:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)
Date: Tue, 14 Mar 2006 15:46:09 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

...

>=20
> I agree that the right balance is important.  My feeling is that we
> need more formality in the RADIUS data model that we have now (which
> is pretty minimal) to enhance interoperability going forwards, and
> allow server vendors who wish to design data dictionary driven
> implementations to do so.  Exactly how much more is the topic we
> should be debating.    =20
>=20
> I've noticed, BTW, that no one on the list has taken up Greg Weber's
> invitation to directly comment upon his latest RADIUS Design
> Guidelines draft.  We seem to be having some of that discussion, in a
> meta-discussion sense, in this thread though.  I suppose that simply
> validates the observation that WG's don't really engage in discussing
> any document until WGLC.  :-) =20

I suggest that WGs do their best work in a non-linear fashion and =
further, that documents are in fact the tangible expression of that =
work, rather than ends in and of themselves.  =20

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 14 Mar 2006 22:54:13 +0000
Content-class: urn:content-classes:message
Subject: Discussion of the RADIUS data model (was RE: New Technical Issues  RE: WG last call in progress on VLAN/Priority Draft)
Date: Tue, 14 Mar 2006 17:53:55 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> I think it depends upon one's interpretation (which is what this
> conversation is about).  BTW, the definition of the "Address" data=20
> type in RFC 2865 is identical (with the exception that addresses=20
> can be signed) to that of "Integer"; what does that mean?=20

Good question.  I don't think I've ever seen the address data type used.
The notion of a signed address confuses me.  :-)

> More to=20
> the point, it doesn't matter to me whether the attribute data field
> in question is defined as a string or an integer, since it is=20
> neither (or both, depending upon your POV).

Well, I suppose it does matter when the encoding on the wire may differ,
or one implementer's interpretation (POV) differs from another's,
resulting in poor interoperability.

> > I'm sure that there are lots of such programs, as C has no=20
> > strong data typing.
>=20
> As you imply below, neither does RADIUS...

I think RFCs 2865/66 have strong, but very limited (and limiting), data
typing.  Once you get beyond those base documents, yes, I think there is
no consistent data model.

> > The substance of this discussion, I think, is whether
> > or not the RADIUS protocol should have meaningful data model,=20
> >and meaningful data types,
>=20
> There are problems with such things, as this conversation=20
> illustrates.  One is that one person's "meaningful type" is=20
> another's "meaningless distinction", leading to (possibly endless)
> discussions akin to those medieval ones involving angels and pins ;-);
> another is the addition of yet another constituency to the debate
> over protocol extension.  How long would it be before we hear from=20
> some server vendor that some perfectly reasonable & extremely useful
> RADIUS extension cannot be adopted because "my parser won't handle=20
> that data type"?

I agree that the right balance is important.  My feeling is that we need
more formality in the RADIUS data model that we have now (which is
pretty minimal) to enhance interoperability going forwards, and allow
server vendors who wish to design data dictionary driven implementations
to do so.  Exactly how much more is the topic we should be debating.

I've noticed, BTW, that no one on the list has taken up Greg Weber's
invitation to directly comment upon his latest RADIUS Design Guidelines
draft.  We seem to be having some of that discussion, in a
meta-discussion sense, in this thread though.  I suppose that simply
validates the observation that WG's don't really engage in discussing
any document until WGLC.  :-)

--
to unsubscribe send a message 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, 14 Mar 2006 22:33:58 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on  VLAN/Priority Draft
Date: Tue, 14 Mar 2006 17:33:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> Eg. the number of hours, minutes and seconds that a session lasted are
> so closely related that we decided to do all kinds of bad, bad magic
to
> those 3 values and pack them together into one attribute:
> Acct-Session-Time.

I think perhaps you are making a jest at my expense.  That's fine; I
have a thick skin.

> If all packing is bad, I suppose you also consider /that/ attribute a
> candidate for a complex data type as well? No?=20

No.

> Why not?

Because RFC 2865 defines a time as a base data type:

time    32 bit unsigned value, most significant octet first --
        seconds since 00:00:00 UTC, January 1, 1970.  The
        standard Attributes do not use this data type but it is
        presented here for possible use in future attributes.

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

Delivery-date: Tue, 14 Mar 2006 21:59:44 +0000
Date: Tue, 14 Mar 2006 22:59:35 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 14, 2006 at 04:47:50PM -0500, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > And in the case of the VLAN attribute, it
> > *does* contain an unsigned integer value, one that's calculated as
> > follows:
> > 
> > value = vlanflag * 16777216 + vlanid
> > 
> > The reverse goes as follows:
> > 
> > vlanflag = value / 16777216
> > vlanid = value % 16777216
> > 
> > (where
> >  * denotes unsigned integer multiplication,
> >  + denotes unsigned integer addition,
> >  / denotes unsigned integer division and
> >  % denotes taking the reminder of an unsigned integer division,
> >  all to be carried out on unsigned integers in the range 0 .. 2**32-1)
> 
> Well, that would be one method of defining the VLANID attribute that
> would clearly an integer data type.

*roffle* Surprise! It's the same definition as the one in the draft.
Calloo, callay, and joy abounds.

Cheers,

Emile.

> > I'm not believing that people on this list would have to be explained
> > that shifting and masking bits are *not* magic operations that you can
> > only perform if you program in assembly (or its portable flavour, C),
> > but that those are normal mathematical operations on normal integers:
> > multiply and take remainder (by powers of 2).
> 
> No.  My point was that packing multiple, separate fields into an opaque
> data container is representing a complex data type, whether you perform
> the packing using bit or octet offsets in a string type or arithmetic
> manipulations on an integer type.  Packing is packing.  :-)

Agreed about that last sentence. But to come to your point: some things
are so closely associated that closely packing them together is *good*.

Eg. the number of hours, minutes and seconds that a session lasted are
so closely related that we decided to do all kinds of bad, bad magic to
those 3 values and pack them together into one attribute:
Acct-Session-Time. 

If all packing is bad, I suppose you also consider /that/ attribute a
candidate for a complex data type as well? No? Why not?

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 14 Mar 2006 21:50:30 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Tue, 14 Mar 2006 13:50:23 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

...

>>> (2) The range is defined as 0 .. 2**32-1.
>>=20
>> But that's not what it _says_; what it _says_ is "32 bit unsigned
>> value".=20
>=20
> Is that not what it means?  I had always thought so.

I think it depends upon one's interpretation (which is what this =
conversation is about).  BTW, the definition of the "Address" data type =
in RFC 2865 is identical (with the exception that addresses can be =
signed) to that of "Integer"; what does that mean?  More to the point, =
it doesn't matter to me whether the attribute data field in question is =
defined as a string or an integer, since it is neither (or both, =
depending upon your POV). =20

>=20
>> Now, everybody who has never written a C program that treated an
>> unsigned long as a string of bits (rather than a whole number) raise
>> their hands ...
>=20
> I'm sure that there are lots of such programs, as C has no strong
> data typing. =20

As you imply below, neither does RADIUS...

> The substance of this discussion, I think, is whether
> or not the RADIUS protocol should have meaningful model, and
> meaningful data types,=20

There are problems with such things, as this conversation illustrates.  =
One is that one person's "meaningful type" is another's "meaningless =
distinction", leading to (possibly endless) discussions akin to those =
medieval ones involving angels and pins ;-); another is the addition of =
yet another constituency to the debate over protocol extension.  How =
long would it be before we hear from some server vendor that some =
perfectly reasonable & extremely useful RADIUS extension cannot be =
adopted because "my parser won't handle that data type"?

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 14 Mar 2006 21:48:02 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on  VLAN/Priority Draft
Date: Tue, 14 Mar 2006 16:47:50 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> And in the case of the VLAN attribute, it
> *does* contain an unsigned integer value, one that's calculated as
> follows:
>=20
> value =3D vlanflag * 16777216 + vlanid
>=20
> The reverse goes as follows:
>=20
> vlanflag =3D value / 16777216
> vlanid =3D value % 16777216
>=20
> (where
>  * denotes unsigned integer multiplication,
>  + denotes unsigned integer addition,
>  / denotes unsigned integer division and
>  % denotes taking the reminder of an unsigned integer division,
>  all to be carried out on unsigned integers in the range 0 .. 2**32-1)

Well, that would be one method of defining the VLANID attribute that
would clearly an integer data type.

> I'm not believing that people on this list would have to be explained
> that shifting and masking bits are *not* magic operations that you can
> only perform if you program in assembly (or its portable flavour, C),
> but that those are normal mathematical operations on normal integers:
> multiply and take remainder (by powers of 2).

No.  My point was that packing multiple, separate fields into an opaque
data container is representing a complex data type, whether you perform
the packing using bit or octet offsets in a string type or arithmetic
manipulations on an integer type.  Packing is packing.  :-)

--
to unsubscribe send a message 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, 14 Mar 2006 21:39:37 +0000
Date: Tue, 14 Mar 2006 22:39:02 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 14, 2006 at 01:27:48PM -0500, Nelson, David wrote:

> [GwZ]
>
> > RFC 2568 says
> > 
> > 	integer   32 bit unsigned value, most significant octet first.
> > 
> > That's it.  No range, no interpretation, nothing else.
> 
> I beg to differ.  The way I interpret this RADIUS data type is as
> follows:
> 
> (1) Its an integer.
> (2) The range is defined as 0 .. 2**32-1.
> (3) Its unsigned.
> (4) Its big-endian.
> 
> I see nothing that indicates this data type is anything other than an
> integer, typically expressed in a C language declaration as "unsigned
> long".

You're completely correct. And in the case of the VLAN attribute, it
*does* contain an unsigned integer value, one that's calculated as follows:

value = vlanflag * 16777216 + vlanid

The reverse goes as follows:

vlanflag = value / 16777216
vlanid = value % 16777216

(where 
 * denotes unsigned integer multiplication, 
 + denotes unsigned integer addition,
 / denotes unsigned integer division and 
 % denotes taking the reminder of an unsigned integer division,
 all to be carried out on unsigned integers in the range 0 .. 2**32-1)

I'm not believing that people on this list would have to be explained
that shifting and masking bits are *not* magic operations that you can
only perform if you program in assembly (or its portable flavour, C),
but that those are normal mathematical operations on normal integers:
multiply and take remainder (by powers of 2).

You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever.
This whole issue has nothing whatsoever to do with C structures.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 14 Mar 2006 19:39:55 +0000
Date: Tue, 14 Mar 2006 14:39:36 -0500
From: Barney Wolff <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: Barney Wolff <[email-masked]>, [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

On Tue, Mar 14, 2006 at 02:42:42PM -0500, Alan DeKok wrote:
> Barney Wolff <[email-masked]> wrote:
> > It seems to me that what's wrong with the attribute is not so much
> > whether it should be called integer or string, but that it is a
> > misuse (or clever hack) of the tag field to have semantic value.
> 
>   But it's not a RADIUS tag field.  It's meaning has no correlation
> with the tag fields of RADIUS tagged attributes, because those tags
> have values 1..0x1f.  Instead, it's using a VLAN tag.

Oops.  Sorry, I misremembered the set of valid tag values.  So my
comments are largely nonsensical.
Barney

--
to unsubscribe send 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, 14 Mar 2006 19:35:07 +0000
From: "Alan DeKok" <[email-masked]>
To: Barney Wolff <[email-masked]>
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Tue, 14 Mar 2006 14:42:42 -0500
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> It seems to me that what's wrong with the attribute is not so much
> whether it should be called integer or string, but that it is a
> misuse (or clever hack) of the tag field to have semantic value.

  But it's not a RADIUS tag field.  It's meaning has no correlation
with the tag fields of RADIUS tagged attributes, because those tags
have values 1..0x1f.  Instead, it's using a VLAN tag.

> That's clear from the allowed values of the first octet, 0x31 or
> 0x32.  So far as I'm aware, tags have only been used for grouping
> and ordering of attribute sets.  Here, what is manifestly
> a tag field is being used to communicate a 1-bit flag value.

  Perhaps calling it "VLAN flag" rather than "VLAN tag" would minimize
confusion.

> I don't even believe that the clever hack will work well, because it
> will allow undefined values (0x32 etc) to escape detection

  I'm not sure what you mean by that.

> and it will make the human-readable form of the attribute look
> misleading.

  That is certainly true.  That's the price to be paid for not having
a machine-readable data model.

  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, 14 Mar 2006 19:22:08 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on  VLAN/Priority Draft
Date: Tue, 14 Mar 2006 14:21:59 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> That they are not is patently false.

Too many layers of negation for me to parse this, but I suspect it
doesn't matter.

> > (1) Its an integer.
>=20
> Impossible.

OK.  Your point is taken.  It's a computer representation of an integer
in 32 bits.

> > (2) The range is defined as 0 .. 2**32-1.
>=20
> But that's not what it _says_; what it _says_ is "32 bit unsigned
value".

Is that not what it means?  I had always thought so.

> Now, everybody who has never written a C program that treated an
> unsigned long as a string of bits (rather than a whole number) raise
> their hands ...

I'm sure that there are lots of such programs, as C has no strong data
typing.  The substance of this discussion, I think, is whether or not
the RADIUS protocol should have meaningful model, and meaningful data
types, not whether or not the C programming language enforces these
properties.

--
to unsubscribe send a message 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, 14 Mar 2006 19:13:50 +0000
Date: Tue, 14 Mar 2006 14:13:47 -0500
From: Barney Wolff <[email-masked]>
Cc: [email-masked]
Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

It seems to me that what's wrong with the attribute is not so much
whether it should be called integer or string, but that it is a
misuse (or clever hack) of the tag field to have semantic value.

That's clear from the allowed values of the first octet, 0x31 or
0x32.  So far as I'm aware, tags have only been used for grouping
and ordering of attribute sets.  Here, what is manifestly
a tag field is being used to communicate a 1-bit flag value.

I don't even believe that the clever hack will work well, because it
will allow undefined values (0x32 etc) to escape detection and
it will make the human-readable form of the attribute look misleading.

Barney

--
to unsubscribe send a message 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, 14 Mar 2006 19:10:06 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Tue, 14 Mar 2006 11:09:49 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

> Glen Zorn writes....
>=20
>> For this to be wrong, there must be a non-infinite representation of
>> any integer.  However, no such representation exists; the proof is
>> left as a (trivial) exercise for the reader.
>=20
> The fact that computer representations of integers cannot take on
> infinite, does not invalidate the point I was attempting to make.=20

You said "Someone offered the suggestion that Integers are not simply =
the mathematical definition, i.e. the positive and negative whole =
numbers and zero, that we all learned in high school.  With all due =
respect, I think that's patently wrong."  That they are not is patently =
false. =20

> BTW, there has been work on indefinite precision arithmetic, which
> permits extensible range integers, but not infinite ones.

That is irrelevant, I think.
  =20
>=20
>> Indeed, there is as much as you want; the questions are, how useful
>> is it to go down that road & (if it is at all useful), how far do we
>> want to go?=20
>=20
> That, indeed, is the crux of the debate.
>=20
>> With all due respect, I think that you are the one doing the
>> overloading: RFC 2568 says=20
>>=20
>> 	integer   32 bit unsigned value, most significant octet first.
>>=20
>> That's it.  No range, no interpretation, nothing else.
>=20
> I beg to differ.  The way I interpret this RADIUS data type is as
> follows:
>=20
> (1) Its an integer.

Impossible.

> (2) The range is defined as 0 .. 2**32-1.

But that's not what it _says_; what it _says_ is "32 bit unsigned =
value".

> (3) Its unsigned.
> (4) Its big-endian.
>=20
> I see nothing that indicates this data type is anything other than an
> integer, typically expressed in a C language declaration as "unsigned
> long".=20

OK, let's just accept this latter statement as valid.  Now, everybody =
who has never written a=20
C program that treated an unsigned long as a string of bits (rather than =
a whole number) raise their hands (& send a note justifying your =
presence on this list ;-).

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 14 Mar 2006 18:28:00 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on  VLAN/Priority Draft
Date: Tue, 14 Mar 2006 13:27:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes....

> For this to be wrong, there must be a non-infinite representation of
any
> integer.  However, no such representation exists; the proof is left as
a
> (trivial) exercise for the reader.

The fact that computer representations of integers cannot take on
infinite, does not invalidate the point I was attempting to make.  BTW,
there has been work on indefinite precision arithmetic, which permits
extensible range integers, but not infinite ones.

> Indeed, there is as much as you want; the questions are, how useful is
it
> to go down that road & (if it is at all useful), how far do we want to
go?

That, indeed, is the crux of the debate.

> With all due respect, I think that you are the one doing the
overloading:
> RFC 2568 says
>=20
> 	integer   32 bit unsigned value, most significant octet first.
>=20
> That's it.  No range, no interpretation, nothing else.

I beg to differ.  The way I interpret this RADIUS data type is as
follows:

(1) Its an integer.
(2) The range is defined as 0 .. 2**32-1.
(3) Its unsigned.
(4) Its big-endian.

I see nothing that indicates this data type is anything other than an
integer, typically expressed in a C language declaration as "unsigned
long".

--
to unsubscribe send a message 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, 14 Mar 2006 18:03:31 +0000
Content-class: urn:content-classes:message
Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Date: Tue, 14 Mar 2006 10:03:20 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

> Submitter name: Dave Nelson
> Submitter email address: [email-masked] Date first submitted:
> March 14, 2006=20
> Reference:
> Document: VLAN/Priority -00
> Comment type: 'T'echnical
> Priority: '1' Should fix
>=20
> Section: 2.1.  Egress-VLANID
> Rationale/Explanation of issue:
>=20
> Misuse of data types.  I had previously raised this issue, and the
> resolution was we could use a RADIUS data type of Integer, because
> only the VLANID (12-bit) portion would be used.  Thus, this object
> could be thought of as a range-limited integer.  Since I see that we
> still have the VLAN Tag fields, that resolution falls apart. I claim
> that this data object is not an Integer.    =20
>=20
> Someone offered the suggestion that Integers are not simply the
> mathematical definition, i.e. the positive and negative whole numbers
> and zero, that we all learned in high school.  With all due respect,
> I think that's patently wrong. =20

For this to be wrong, there must be a non-infinite representation of any =
integer.  However, no such representation exists; the proof is left as a =
(trivial) exercise for the reader.

> It is true that one can write
> programs that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as
> packed data structures using mask, bit-field, shift and rotate
> operations.  I still claim that those data structures are *not*
> integers simply because they can be packed within the computer memory
> storage that is also used by integers.  Hopefully, there is more to
> data modeling than the storage length in bits.  :-) =20

Indeed, there is as much as you want; the questions are, how useful is =
it to go down that road & (if it is at all useful), how far do we want =
to go?
     =20
>=20
> We are currently having a debate on the RADEXT WG list about the
> issue of derived data types, and no consensus has yet been reached.=20
> However, until such a consensus is reached, it seems most appropriate
> to follow the existing practice of defining derived data types as
> Strings, with the bit-fields described in the text.  I think that
> over-loading base RADIUS data types with new meanings is
> inappropriate. =20

With all due respect, I think that you are the one doing the =
overloading: RFC 2568 says=20

	integer   32 bit unsigned value, most significant octet first.

That's it.  No range, no interpretation, nothing else.

> Given the relative timing of WGLC on this draft and
> the emerging consensus on RADIUS Attribute Design Guidelines, I think
> this is the best compromise.=20

I think that the best compromise is to strictly interpret RFC 2568.
      =20
>=20
> Requested change:
>=20
> OLD:
>=20
> Integer
>=20
>       The Integer field is four octets in length.  The format is
>       described below:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     =20
>     =20
>     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20
> VLAN  Tag    |        Pad            |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =20
>=20
>       The VLAN Tag field is one octet in length, and indicates whether
>       the frames on the VLAN are tagged (0x31) or untagged (0x32).=20
>       The Pad field is 12-bits in length and MUST be 0 (zero). The
>       VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN
> VID value.=20
>=20
>=20
> NEW:
>=20
> String
>=20
>       The String field is four octets in length.  The format is
>       described below:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     =20
>     =20
>     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20
> VLAN  Tag    |        Pad            |       VLANID          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =20
>=20
>       The VLAN Tag field is one octet in length, and indicates whether
>       the frames on the VLAN are tagged (0x31) or untagged (0x32).=20
>       The Pad field is 12-bits in length and MUST be 0 (zero). The
>       VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN
> VID value.=20
>=20
>=20
> Section: 2.3.  Egress-VLAN-Name
> Rationale/Explanation of issue:
>=20
> I'm rather uncomfortable with the usage of the VLAN Tag field, as it
> seems to be at variance with the emerging WG consensus on complex or
> structured data types.  Once we standardize this usage, there will be
> one more precedent in a RADIUS RFC to support ad-hoc data typing.  If
> that's what RADEXT ultimately recommends, then this will be fine.  If
> the recommendation is to use a more formal method of aggregating
> structured data, this will be one more anomaly.     =20
>=20
> VLAN Tag
>=20
>       The VLAN tag field is one octet in length, and indicates whether
>       the frames on the VLAN are tagged (0x31) or untagged (0x32).
>=20
> Requested change:
>=20
> I have no idea what (if any change) to request.  Chalk this comment
> up as my personal lament over the process that RADEXT has followed --
> delaying consensus on attributes design to the point where we are
> standardizing new attributes using complex data types prior to having
> defined the design guidelines for complex data types.   =20
>=20
>=20
> Section 2.4 User-Priority-Table
> Rationale/Explanation of issue:
>=20
> With all due deference to the well understood "array - string
> duality" we find in programming languages such as C, I think that
> expressing a attribute whose value is an array in the form of a
> RADIUS String type is unfortunate, for the reasons expressed above.  =20
>=20
> Requested change:
>=20
> (See above.)
>=20
> The only way that I see to actually resolve my data typing / data
> modeling concerns is to delay sending any RADEXT work item that uses
> derived data types to the IESG until after we have sent the RADIUS
> Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG,
> and that approach is not compatible with our milestones.   =20
>=20
> Regards,
>=20
> Dave
>=20
> David B. Nelson
> Enterasys Networks, Inc.
> 50 Minuteman Road
> Andover, MA 01810-1008
> Phone: (978) 684-1330
> E-mail: [email-masked]

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send 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, 14 Mar 2006 17:43:34 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft 
cc: [email-masked]
Date: Tue, 14 Mar 2006 12:50:27 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> NOTE: 5 reviews are required for the document to advance as a Proposed 
> Standard.  If you have read the document, please post your opinion to the 
> list, even if you have no issues to file:

  I'm OK with it.  I have no additional 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: Tue, 14 Mar 2006 16:50:24 +0000
Content-class: urn:content-classes:message
Subject: New Technical Issues RE: WG last call in progress on VLAN/Priority  Draft
Date: Tue, 14 Mar 2006 11:50:18 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: March 14, 2006
Reference:
Document: VLAN/Priority -00
Comment type: 'T'echnical
Priority: '1' Should fix

Section: 2.1.  Egress-VLANID
Rationale/Explanation of issue:

Misuse of data types.  I had previously raised this issue, and the =
resolution was we could use a RADIUS data type of Integer, because only =
the VLANID (12-bit) portion would be used.  Thus, this object could be =
thought of as a range-limited integer.  Since I see that we still have =
the VLAN Tag fields, that resolution falls apart. I claim that this data =
object is not an Integer.

Someone offered the suggestion that Integers are not simply the =
mathematical definition, i.e. the positive and negative whole numbers =
and zero, that we all learned in high school.  With all due respect, I =
think that's patently wrong.  It is true that one can write programs =
that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data =
structures using mask, bit-field, shift and rotate operations.  I still =
claim that those data structures are *not* integers simply because they =
can be packed within the computer memory storage that is also used by =
integers.  Hopefully, there is more to data modeling than the storage =
length in bits.  :-)

We are currently having a debate on the RADEXT WG list about the issue =
of derived data types, and no consensus has yet been reached.  However, =
until such a consensus is reached, it seems most appropriate to follow =
the existing practice of defining derived data types as Strings, with =
the bit-fields described in the text.  I think that over-loading base =
RADIUS data types with new meanings is inappropriate.  Given the =
relative timing of WGLC on this draft and the emerging consensus on =
RADIUS Attribute Design Guidelines, I think this is the best compromise.

Requested change:

OLD:

Integer

      The Integer field is four octets in length.  The format is
      described below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN  Tag    |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The VLAN Tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).  The
      Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
      12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.

NEW:

String

      The String field is four octets in length.  The format is
      described below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN  Tag    |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The VLAN Tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).  The
      Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
      12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.

Section: 2.3.  Egress-VLAN-Name
Rationale/Explanation of issue:

I'm rather uncomfortable with the usage of the VLAN Tag field, as it =
seems to be at variance with the emerging WG consensus on complex or =
structured data types.  Once we standardize this usage, there will be =
one more precedent in a RADIUS RFC to support ad-hoc data typing.  If =
that's what RADEXT ultimately recommends, then this will be fine.  If =
the recommendation is to use a more formal method of aggregating =
structured data, this will be one more anomaly.

VLAN Tag

      The VLAN tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).

Requested change:

I have no idea what (if any change) to request.  Chalk this comment up =
as my personal lament over the process that RADEXT has followed -- =
delaying consensus on attributes design to the point where we are =
standardizing new attributes using complex data types prior to having =
defined the design guidelines for complex data types.=20

Section 2.4 User-Priority-Table
Rationale/Explanation of issue:

With all due deference to the well understood "array - string duality" =
we find in programming languages such as C, I think that expressing a =
attribute whose value is an array in the form of a RADIUS String type is =
unfortunate, for the reasons expressed above.

Requested change:

(See above.)

The only way that I see to actually resolve my data typing / data =
modeling concerns is to delay sending any RADEXT work item that uses =
derived data types to the IESG until after we have sent the RADIUS =
Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, and =
that approach is not compatible with our milestones.

Regards,
=A0
Dave
=A0
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330=A0=20
E-mail: [email-masked]
=A0

--
to unsubscribe send a message 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, 14 Mar 2006 16:44:41 +0000
Content-class: urn:content-classes:message
Subject: New Editorial Issues RE: WG last call in progress on VLAN/Priority  Draft
Date: Tue, 14 Mar 2006 11:44:14 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: March 14, 2006
Reference:
Document: VLAN/Priority -00
Comment type: 'E'ditorial
Priority: '1' Should fix

Section: 1.3 Attribute Interpretation
Rationale/Explanation of issue: missing quote
Requested change:
s/value set to Unsupported Attribute" (401)/value set to "Unsupported
Attribute" (401)/

--
to unsubscribe send a message 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, 14 Mar 2006 15:36:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: PLEASE READ: WG last call in progress on RADIUS Delegated IPv6 Prefix Attribute
Date: Tue, 14 Mar 2006 07:35:57 -0800

There is a RADEXT WG last call in progress on the RADIUS Delegated IPv6 
Prefix Attribute document, prior to sending it on to the IESG for 
consideration as a Proposed Standard.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt

RADEXT WG last call will last until Monday March 27, 2006.  Please send your
comments to the RADEXT WG list ([email-masked]) in the format 
described
on the RADEXT Issues List:
http://www.drizzle.com/~aboba/RADEXT/

NOTE: 5 reviews are required for the document to advance as a Proposed 
Standard.  If you have read the document, please post your opinion to the 
list, even if you have no issues to file.  For example, if you support 
publication of this document, please send a message to the list to this 
effect.  Currently, insufficient reviews have been posted to allow this 
document to advance.

--
to unsubscribe send a message 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, 14 Mar 2006 15:31:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft
Date: Tue, 14 Mar 2006 07:30:21 -0800

There is a RADEXT WG last call in progress on the VLAN and Priority 
Attributes document, prior to sending it on to the IESG for consideration as 
a Proposed Standard.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt

RADEXT WG last call will last until Friday, March 17, 2006. Please send your
comments to the RADEXT WG mailing list ([email-masked]) in the format 
described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

NOTE: 5 reviews are required for the document to advance as a Proposed 
Standard.  If you have read the document, please post your opinion to the 
list, even if you have no issues to file:

So far, only two reviews have been received:
http://ops.ietf.org/lists/radiusext/2006/msg00169.html
http://ops.ietf.org/lists/radiusext/2006/msg00225.html

--
to unsubscribe send a message 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, 14 Mar 2006 08:27:51 +0000
Date: Tue, 14 Mar 2006 09:26:56 +0100
From: [email-masked]
To: "Nelson, David" <[email-masked]>
Cc: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked], "Wijnen, Bert \(Bert\)" <[email-masked]>
Subject: Re: radius dynauth client/server mibs structure

This is a multi-part message in MIME format.
--------------040706070208020204040408
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

And here is the correct client MIB. Sorry for the duplicate server MIB.

Thanks,
Stefaan

Nelson, David wrote:

> Stefaan,
> 
> It appears that the two revised draft version files you sent today were
> both the server MIB.
> 
> -- Dave
> 

--------------040706070208020204040408
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
 name="draft-ietf-radext-dynauth-client-mib-04.txt"
Content-Disposition: inline;
 filename="draft-ietf-radext-dynauth-client-mib-04.txt"

Network Working Group                                      S. De Cnodder
Internet-Draft                                                   Alcatel
Expires: September 15, 2006                                   N. Jonnala
                                                                M. Chiba
                                                     Cisco Systems, Inc.
                                                          March 14, 2006

                    Dynamic Authorization Client MIB
              draft-ietf-radext-dynauth-client-mib-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 15, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

De Cnodder, et al.     Expires September 15, 2006               [Page 1]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  RADIUS Dynamic Authorization Client MIB Definitions  . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 23
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 28

De Cnodder, et al.     Expires September 15, 2006               [Page 2]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   It is becoming increasingly important to support Dynamic
   Authorization extensions on the network access server (NAS) devices
   to handle the Disconnect and Change-of-Authorization (CoA) messages
   as described in [RFC3576].  As a result, the effective management of
   RADIUS Dynamic Authorization entities is of considerable importance.
   This RADIUS Dynamic Authorization Client MIB complements the managed
   objects used for managing RADIUS authentication and accounting
   servers as described in [RFC2619bis] and [RFC2621bis], respectively.

   -- RFC Ed.: references [DYNSERV], [RFC2619bis], [RFC2621bis] should
   --          be replaced by references to the corresponding RFC.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS which processes the Disconnect
   and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
   the Dynamic Authorization Client.

   Dynamic Authorization Client (DAC)

   The component which sends Disconnect and CoA-Request packets to the
   Dynamic Authorization Server.  While often residing on the RADIUS
   server, it is also possible for this component to be located on a
   separate host, such as a Rating Engine.

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization Server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client.

De Cnodder, et al.     Expires September 15, 2006               [Page 3]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580
   [RFC2580].

De Cnodder, et al.     Expires September 15, 2006               [Page 4]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

3.  Overview

   "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the
   operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-
   Request, CoA-ACK and CoA-NAK packets.  [DYNSERV] defines the Dynamic
   Authorization Server MIB and the relationship with other MIB modules.
   This MIB module for the Dynamic Authorization Client contains the
   following:

   1.  Two scalar objects, and

   2.  One Dynamic Authorization Server table.  This table contains one
   row for each DAS that the DAC shares a secret with.

De Cnodder, et al.     Expires September 15, 2006               [Page 5]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

4.  RADIUS Dynamic Authorization Client MIB Definitions

   RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS ::= BEGIN

   IMPORTS
          MODULE-IDENTITY, OBJECT-TYPE,
          Counter32, Gauge32, Integer32,
          mib-2, TimeTicks    FROM SNMPv2-SMI         -- [RFC2578]
          SnmpAdminString     FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
          InetAddressType, InetAddress,
          InetPortNumber      FROM INET-ADDRESS-MIB   -- [RFC4001]
          MODULE-COMPLIANCE,
          OBJECT-GROUP FROM SNMPv2-CONF;              -- [RFC2580]

   radiusDynAuthClientMIB MODULE-IDENTITY
          LAST-UPDATED "200603100000Z" -- 10 March 2006
          ORGANIZATION "IETF RADEXT Working Group"
          CONTACT-INFO
                 " Stefaan De Cnodder
                   Alcatel
                   Francis Wellesplein 1
                   B-2018 Antwerp
                   Belgium

                   Phone: +32 3 240 85 15
                   EMail: [email-masked]

                   Nagi Reddy Jonnala
                   Cisco Systems, Inc.
                   Divyasree Chambers, B Wing,
                   O'Shaugnessy Road,
                   Bangalore-560027, India.

                   Phone: +91 98456 99445
                   EMail: [email-masked]

                   Murtaza Chiba
                   Cisco Systems, Inc.
                   170 West Tasman Dr.
                   San Jose CA, 95134

                   Phone: +1 408 525 7198
                   EMail: [email-masked] "
          DESCRIPTION
              "The MIB module for entities implementing the client
               side of the Dynamic Authorization Extensions to Remote
               Authentication Dial In User Service (RADIUS) protocol.

De Cnodder, et al.     Expires September 15, 2006               [Page 6]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

               Copyright (C) The Internet Society (2006).  Initial
               version as published in RFC yyyy;
               for full legal notices see the RFC itself."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

          REVISION "200603100000Z" -- 10 March 2006
          DESCRIPTION "Initial version as published in RFC yyyy"
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
          ::= { mib-2 xxx }
   -- The value xxx to be assigned by IANA.

   radiusDynAuthClientMIBObjects OBJECT IDENTIFIER ::=
                                         { radiusDynAuthClientMIB 1 }

   radiusDynAuthClientScalars    OBJECT IDENTIFIER ::=
                                  { radiusDynAuthClientMIBObjects 1 }

   radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE
          SYNTAX Counter32
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
                "The number of Disconnect-Ack and Disconnect-NAK packets
                 received from unknown addresses. This counter wraps
                 from the maximum value to zero and is reset upon system
                 (re)initialization."
          ::= { radiusDynAuthClientScalars 1 }

   radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE
          SYNTAX Counter32
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
                "The number of CoA-Ack and CoA-NAK packets received from
                 unknown addresses. This counter wraps from the maximum
                 value to zero and is reset upon system
                 (re)initialization."
          ::= { radiusDynAuthClientScalars 2 }

   radiusDynAuthServerTable OBJECT-TYPE
          SYNTAX SEQUENCE OF RadiusDynAuthServerEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "The (conceptual) table listing the RADIUS Dynamic
                 Authorization Servers with which the client shares a
                 secret."
          ::= { radiusDynAuthClientMIBObjects 2 }

De Cnodder, et al.     Expires September 15, 2006               [Page 7]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

   radiusDynAuthServerEntry OBJECT-TYPE
          SYNTAX     RadiusDynAuthServerEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "An entry (conceptual row) representing one Dynamic
                 Authorization Server with which the client shares a
                 secret."
          INDEX      { radiusDynAuthServerIndex }
          ::= { radiusDynAuthServerTable 1 }

   RadiusDynAuthServerEntry ::= SEQUENCE {
          radiusDynAuthServerIndex                     Integer32,
          radiusDynAuthServerAddressType               InetAddressType,
          radiusDynAuthServerAddress                   InetAddress,
          radiusDynAuthServerClientPortNumber          InetPortNumber,
          radiusDynAuthServerID                        SnmpAdminString,
          radiusDynAuthClientRoundTripTime             TimeTicks,
          radiusDynAuthClientDisconRequests            Counter32,
          radiusDynAuthClientDisconAuthOnlyRequests    Counter32,
          radiusDynAuthClientDisconRetransmissions     Counter32,
          radiusDynAuthClientDisconAcks                Counter32,
          radiusDynAuthClientDisconNaks                Counter32,
          radiusDynAuthClientDisconNakAuthOnlyRequest  Counter32,
          radiusDynAuthClientDisconNakSessNoContext    Counter32,
          radiusDynAuthClientMalformedDisconResponses  Counter32,
          radiusDynAuthClientDisconBadAuthenticators   Counter32,
          radiusDynAuthClientDisconPendingRequests     Gauge32,
          radiusDynAuthClientDisconTimeouts            Counter32,
          radiusDynAuthClientDisconPacketsDropped      Counter32,
          radiusDynAuthClientCoARequests               Counter32,
          radiusDynAuthClientCoAAuthOnlyRequest        Counter32,
          radiusDynAuthClientCoARetransmissions        Counter32,
          radiusDynAuthClientCoAAcks                   Counter32,
          radiusDynAuthClientCoANaks                   Counter32,
          radiusDynAuthClientCoANakAuthOnlyRequest     Counter32,
          radiusDynAuthClientCoANakSessNoContext       Counter32,
          radiusDynAuthClientMalformedCoAResponses     Counter32,
          radiusDynAuthClientCoABadAuthenticators      Counter32,
          radiusDynAuthClientCoAPendingRequests        Gauge32,
          radiusDynAuthClientCoATimeouts               Counter32,
          radiusDynAuthClientCoAPacketsDropped         Counter32,
          radiusDynAuthClientUnknownTypes              Counter32
   }

   radiusDynAuthServerIndex OBJECT-TYPE
          SYNTAX     Integer32 (1..2147483647)

De Cnodder, et al.     Expires September 15, 2006               [Page 8]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "A number uniquely identifying each RADIUS Dynamic
                 Authorization Server with which this Dynamic
                 Authorization Client communicates. This number is
                 allocated by the agent implementing this MIB module,
                 and is unique in this context."
          ::= { radiusDynAuthServerEntry 1 }

   radiusDynAuthServerAddressType OBJECT-TYPE
          SYNTAX     InetAddressType
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The type of IP address of the RADIUS Dynamic
                 Authorization Server referred to in this table entry."
          ::= { radiusDynAuthServerEntry 2 }

   radiusDynAuthServerAddress OBJECT-TYPE
          SYNTAX     InetAddress
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The IP address value of the RADIUS Dynamic
                 Authorization Server referred to in this table entry
                 using the version neutral IP address format."
          ::= { radiusDynAuthServerEntry 3 }

   radiusDynAuthServerClientPortNumber OBJECT-TYPE
          SYNTAX     InetPortNumber
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The UDP destination port that the RADIUS Dynamic
                 Authorization Client is using to send requests to this
                 server."
          ::= { radiusDynAuthServerEntry 4 }

   radiusDynAuthServerID OBJECT-TYPE
          SYNTAX     SnmpAdminString
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The NAS-Identifier of the RADIUS Dynamic Authorization
                 Server referred to in this table entry. This is not
                 necessarily the same as sysName in MIB II."

De Cnodder, et al.     Expires September 15, 2006               [Page 9]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          REFERENCE
                "RFC 2865, Section 5.32, NAS-Identifier."
          ::= { radiusDynAuthServerEntry 5 }

   radiusDynAuthClientRoundTripTime OBJECT-TYPE
          SYNTAX     TimeTicks
          UNITS      "hundredths of a second"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The time interval (in hundredths of a second) between
                 the most recent Disconnect or CoA request and the
                 reception of the corresponding Disconnect or CoA reply.
                 A value of zero is returned in case no reply has been
                 received yet from this server."
          ::= { radiusDynAuthServerEntry 6 }

   radiusDynAuthClientDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests sent
                 to this Dynamic Authorization Server. This also
                 includes the RADIUS Disconnect-Requests that have a
                 Service-Type attribute with value 'Authorize Only'.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 7 }

   radiusDynAuthClientDisconAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests that include a
                 Service-Type attribute with value 'Authorize Only'
                 sent to this Dynamic Authorization Server. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 8 }

De Cnodder, et al.     Expires September 15, 2006              [Page 10]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

   radiusDynAuthClientDisconRetransmissions OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "retransmissions"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-request packets
                 retransmitted to this RADIUS Dynamic Authorization
                 Server. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 9 }

   radiusDynAuthClientDisconAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-ACK packets
                 received from this Dynamic Authorization Server. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 10 }

   radiusDynAuthClientDisconNaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 received from this Dynamic Authorization Server.
                 This includes the RADIUS Disconnect-NAK packets
                 received with a Service-Type attribute with value
                 'Authorize Only' and the RADIUS Disconnect-NAK
                 packets received no session context was found. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 11 }

   radiusDynAuthClientDisconNakAuthOnlyRequest OBJECT-TYPE
          SYNTAX     Counter32

De Cnodder, et al.     Expires September 15, 2006              [Page 11]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 that include a Service-Type attribute with value
                 'Authorize Only' received from this Dynamic
                 Authorization Server. This counter wraps from the
                 maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 12 }

   radiusDynAuthClientDisconNakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 received from this Dynamic Authorization Server
                 because no session context was found, i.e. it
                 includes an Error-Cause attribute with value 503
                 ('Session Context Not Found'). This counter wraps
                 from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 13 }

   radiusDynAuthClientMalformedDisconResponses OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS Disconnect-Ack and
                 Disconnect-NAK packets received from this Dynamic
                 Authorization Server. Bad authenticators and unknown
                 types are not included as malformed Disconnect-Ack and
                 Disconnect-NAK packets. This counter wraps from the
                 maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 14 }

De Cnodder, et al.     Expires September 15, 2006              [Page 12]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

   radiusDynAuthClientDisconBadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Ack and Disconnect-NAK
                 packets which contained invalid Authenticator field
                 received from this Dynamic Authorization Server. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 15 }

   radiusDynAuthClientDisconPendingRequests OBJECT-TYPE
          SYNTAX     Gauge32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-request packets
                 destined for this server that have not yet timed out
                 or received a response. This variable is incremented
                 when an Disconnect-Request is sent and decremented
                 due to receipt of an Disconnect-Ack, Disconnect-NAK
                 or a timeout or a retransmission."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthServerEntry 16 }

   radiusDynAuthClientDisconTimeouts OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "timeouts"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of Disconnect request timeouts to this
                 server. After a timeout the client may retry to the
                 same server or give up. A retry to the same server is
                 counted as a retransmit as well as a timeout. A send
                 to a different server is counted as a
                 Disconnect-Request as well as a timeout. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."

De Cnodder, et al.     Expires September 15, 2006              [Page 13]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          ::= { radiusDynAuthServerEntry 17 }

   radiusDynAuthClientDisconPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming Disconnect-Ack and
                 Disconnect-NAK packets from this Dynamic Authorization
                 Server silently discarded by the client application for
                 some reason other than malformed, bad authenticators or
                 unknown types. This counter wraps from the maximum
                 value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 18 }

   radiusDynAuthClientCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-Requests sent to this
                 Dynamic Authorization Server. This also includes
                 the CoA requests that have a Service-Type attribute
                 with value 'Authorize Only'. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 19 }

   radiusDynAuthClientCoAAuthOnlyRequest OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-requests that include a
                 Service-Type attribute with value 'Authorize Only'
                 sent to this Dynamic Authorization Client. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."

De Cnodder, et al.     Expires September 15, 2006              [Page 14]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 20 }

   radiusDynAuthClientCoARetransmissions OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "retransmissions"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-request packets
                 retransmitted to this RADIUS Dynamic Authorization
                 Server. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 21 }

   radiusDynAuthClientCoAAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-ACK packets received from
                 this Dynamic Authorization Server. This counter wraps
                 from the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 22 }

   radiusDynAuthClientCoANaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets received from
                 this Dynamic Authorization Server. This includes the
                 RADIUS CoA-NAK packets received with a Service-Type
                 attribute with value 'Authorize Only' and the RADIUS
                 CoA-NAK packets received because no session context
                 was found. This counter wraps from the maximum value
                 to zero and is reset upon system (re)initialization."

De Cnodder, et al.     Expires September 15, 2006              [Page 15]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 23 }

   radiusDynAuthClientCoANakAuthOnlyRequest OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets that include a
                 Service-Type attribute with value 'Authorize Only'
                 received from this Dynamic Authorization Server. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 24 }

   radiusDynAuthClientCoANakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets received from
                 this Dynamic Authorization Server because no session
                 context was found, i.e. it includes an Error-Cause
                 attribute with value 503 ('Session Context Not Found').
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 25 }

   radiusDynAuthClientMalformedCoAResponses OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS CoA-Ack and CoA-NAK
                 packets received from this Dynamic Authorization
                 Server. Bad authenticators and unknown types are
                 not included as malformed CoA-Ack and CoA-NAK packets.

De Cnodder, et al.     Expires September 15, 2006              [Page 16]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 26 }

   radiusDynAuthClientCoABadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-Ack and CoA-NAK packets
                 which contained invalid Authenticator field
                 received from this Dynamic Authorization Server.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 27 }

   radiusDynAuthClientCoAPendingRequests OBJECT-TYPE
          SYNTAX     Gauge32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-request packets destined for
                 this server that have not yet timed out or received a
                 response. This variable is incremented when an
                 CoA-Request is sent and decremented due to receipt of
                 a CoA-Ack, CoA-NAK or a timeout or a retransmission.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 28 }

   radiusDynAuthClientCoATimeouts OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "timeouts"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of CoA request timeouts to this server.

De Cnodder, et al.     Expires September 15, 2006              [Page 17]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

                 After a timeout the client may retry to the same
                 server or give up. A retry to the same server is
                 counted as a retransmit as well as a timeout. A send to
                 a different server is counted as a CoA-Request as well
                 as a timeout. This counter wraps from the maximum value
                 to zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthServerEntry 29 }

   radiusDynAuthClientCoAPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming CoA-Ack and CoA-NAK from this
                 Dynamic Authorization Server silently discarded by the
                 client application for some reason other than
                 malformed, bad authenticators or unknown types. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 30 }

   radiusDynAuthClientUnknownTypes OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming packets of unknown types
                 which were received on the Dynamic Authorization port.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.3, Packet Format."
          ::= { radiusDynAuthServerEntry 31 }

   -- conformance information

   radiusDynAuthClientMIBConformance
          OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 2 }
   radiusDynAuthClientMIBCompliances
          OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 1 }

De Cnodder, et al.     Expires September 15, 2006              [Page 18]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

   radiusDynAuthClientMIBGroups
          OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 2 }

   -- compliance statements

   radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE
          STATUS  current
          DESCRIPTION
                "The compliance statement for entities implementing
                 the RADIUS Dynamic Authorization Client."
          MODULE  -- this module
          MANDATORY-GROUPS { radiusDynAuthClientMIBGroup }

          GROUP              radiusDynAuthClientAuthOnlyGroup
          DESCRIPTION
                "Only required for Dynamic Authorization Clients that
                 are supporting Service-Type attributes with value
                 'Authorize-Only'."

          GROUP              radiusDynAuthClientNoSessGroup
          DESCRIPTION
                "This group is not required in case the Dynamic
                 Authorization Server can not easily determine whether
                 a session exists or not (e.g., in case of a RADIUS
                 proxy)."

          ::= { radiusDynAuthClientMIBCompliances 1 }

   -- units of conformance

   radiusDynAuthClientMIBGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthClientDisconInvalidServerAddresses,
                    radiusDynAuthClientCoAInvalidServerAddresses,
                    radiusDynAuthServerAddressType,
                    radiusDynAuthServerAddress,
                    radiusDynAuthServerClientPortNumber,
                    radiusDynAuthServerID,
                    radiusDynAuthClientRoundTripTime,
                    radiusDynAuthClientDisconRequests,
                    radiusDynAuthClientDisconRetransmissions,
                    radiusDynAuthClientDisconAcks,
                    radiusDynAuthClientDisconNaks,
                    radiusDynAuthClientMalformedDisconResponses,
                    radiusDynAuthClientDisconBadAuthenticators,
                    radiusDynAuthClientDisconPendingRequests,
                    radiusDynAuthClientDisconTimeouts,
                    radiusDynAuthClientDisconPacketsDropped,

De Cnodder, et al.     Expires September 15, 2006              [Page 19]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

                    radiusDynAuthClientCoARequests,
                    radiusDynAuthClientCoARetransmissions,
                    radiusDynAuthClientCoAAcks,
                    radiusDynAuthClientCoANaks,
                    radiusDynAuthClientMalformedCoAResponses,
                    radiusDynAuthClientCoABadAuthenticators,
                    radiusDynAuthClientCoAPendingRequests,
                    radiusDynAuthClientCoATimeouts,
                    radiusDynAuthClientCoAPacketsDropped,
                    radiusDynAuthClientUnknownTypes
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects providing management of
                 a RADIUS Dynamic Authorization Client."
          ::= { radiusDynAuthClientMIBGroups 1 }

   radiusDynAuthClientAuthOnlyGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthClientDisconAuthOnlyRequests,
                    radiusDynAuthClientDisconNakAuthOnlyRequest,
                    radiusDynAuthClientCoAAuthOnlyRequest,
                    radiusDynAuthClientCoANakAuthOnlyRequest
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages including Service-Type attribute with
                 value 'Authorize Only'."
          ::= { radiusDynAuthClientMIBGroups 2 }

   radiusDynAuthClientNoSessGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthClientDisconNakSessNoContext,
                    radiusDynAuthClientCoANakSessNoContext
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages that are referring to non existing sessions."
          ::= { radiusDynAuthClientMIBGroups 3 }

   END

De Cnodder, et al.     Expires September 15, 2006              [Page 20]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

5.  Security Considerations

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   radiusDynAuthServerAddress and radiusDynAuthServerAddressType

   These can be used to determine the address of the DAS with which the
   DAC is communicating.  This information could be useful in mounting
   an attack on the DAS.

   radiusDynAuthServerID

   This can be used to determine the Identifier of the DAS.  This
   information could be useful in impersonating the DAS.

   radiusDynAuthServerClientPortNumber

   This can be used to determine the destination port number to which
   the DAC is sending.  This information could be useful in mounting an
   attack on the DAS.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an

De Cnodder, et al.     Expires September 15, 2006              [Page 21]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

De Cnodder, et al.     Expires September 15, 2006              [Page 22]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

6.  IANA considerations

   IANA is requested to assign an OID under mib-2.

De Cnodder, et al.     Expires September 15, 2006              [Page 23]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

7.  Acknowledgements

   The authors would also like to acknowledge the following people for
   their comments on this document: Bernard Aboba, Alan DeKok, David
   Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg
   Weber, Bert Wijnen, and Glen Zorn.

De Cnodder, et al.     Expires September 15, 2006              [Page 24]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Structure of Management
              Information Version 2 (SMIv2)", STD 58, RFC 2578,
              April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Textual Conventions for
              SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Conformance Statements for
              SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC4001]  Daniele, M. and et al., "Textual Conventions for Internet
              Network Addresses", RFC 4001, February 2005.

8.2.  Informative References

   [DYNSERV]  De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic
              Authorization Server MIB",
              draft-ietf-radext-dynauth-server-mib-03.txt, work in
              progress, December 2005.

   [RFC2619bis]
              Nelson, D., "RADIUS Auth Server MIB (IPv6)",
              draft-ietf-radext-rfc2619bis-01.txt work in progress,
              October 2005.

   [RFC2621bis]
              Nelson, D., "RADIUS Acct Server MIB (IPv6)",
              draft-ietf-radext-rfc2621bis-01.txt work in progress,

De Cnodder, et al.     Expires September 15, 2006              [Page 25]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

              October 2005.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

De Cnodder, et al.     Expires September 15, 2006              [Page 26]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

Authors' Addresses

   Stefaan De Cnodder
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerp
   Belgium

   Phone: +32 3 240 85 15
   Email: [email-masked]

   Nagi Reddy Jonnala
   Cisco Systems, Inc.
   Divyasree Chambers,  B Wing, O'Shaugnessy Road
   Bangalore-560027, India

   Phone: +91 98456 99445
   Email: [email-masked]

   Murtaza Chiba
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose CA, 95134

   Phone: +1 408 525 7198
   Email: [email-masked]

De Cnodder, et al.     Expires September 15, 2006              [Page 27]

Internet-Draft      Dynamic Authorization Client MIB          March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

De Cnodder, et al.     Expires September 15, 2006              [Page 28]


--------------040706070208020204040408--

--
to unsubscribe send a message 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, 13 Mar 2006 22:10:13 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 13 Mar 2006 17:09:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>

Stefaan,

It appears that the two revised draft version files you sent today were
both the server MIB.

-- Dave

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

Delivery-date: Mon, 13 Mar 2006 21:06:05 +0000
Date: Mon, 13 Mar 2006 22:05:21 +0100
From: [email-masked]
To: "Nelson, David" <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: radius dynauth client/server mibs structure

This is a multi-part message in MIME format.
--------------060703020402050606000906
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi Bert, Dave,

The updated versions are attached.

Changes are:
- change 2005 into 2006 in DESCRIPTION of MIB
- group the scalars according the comment of Juergen
- add sentence "This counter wraps from the maximum value to zero and is
reset upon system (re)initialization." for all counters of type
Counter32
- remove ref to IANA copyright.
- some minor formatting (line breaks in the mib)

I tried a diff but that output is rather messy, so I sent you the 
complete drafts.

Thanks,
Stefaan

Nelson, David wrote:

> Bert writes...
> 
> 
>>I am happy to chekc a pre-release rev 04 as well.
> 
> 
>>>Stefaan DeCnodder writes...
>>>
>>>Since the suggestion has sufficient support it is best to
>>>do so. Is it Ok to sent a version -04 of both docs after the 
>>>IETF containing all updates?
> 
> 
> I think Bert would like to get this document revision submitted ASAP.
> The IETF I-D Tracker tool has these documents in the "Revised I-D
> Required" state.
> 
> Bert will be stepping down as O&M Area Director after IETF-65, so if
> these documents are still awaiting IESG approval after next week, then
> they will need to be handed off to another AD for shepherding.
> 
> -- Dave
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--------------060703020402050606000906
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
 name="draft-ietf-radext-dynauth-client-mib-04.txt"
Content-Disposition: inline;
 filename="draft-ietf-radext-dynauth-client-mib-04.txt"

Network Working Group                                      S. De Cnodder
Internet-Draft                                                   Alcatel
Expires: September 14, 2006                                   N. Jonnala
                                                                M. Chiba
                                                     Cisco Systems, Inc.
                                                          March 13, 2006

                    Dynamic Authorization Server MIB
              draft-ietf-radext-dynauth-server-mib-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

De Cnodder, et al.     Expires September 14, 2006               [Page 1]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  RADIUS Dynamic Authorization Server MIB Definitions  . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

De Cnodder, et al.     Expires September 14, 2006               [Page 2]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   It is becoming increasingly important to support Dynamic
   Authorization extensions on the network access server (NAS) devices
   to handle the Disconnect and Change-of-Authorization (CoA) messages
   as described in [RFC3576].  As a result, the effective management of
   RADIUS Dynamic Authorization entities is of considerable importance.
   This RADIUS Dynamic Authorization Server (DAS) MIB complements the
   managed objects used for managing RADIUS authentication and
   accounting clients as described in [RFC2618bis] and [RFC2620bis],
   respectively.

   -- RFC Ed.: references [DYNSERV], [RFC2618bis], [RFC2619bis],
   --          [RFC2620bis], and [RFC2621bis] should be replaced by
   --          references to the corresponding RFC.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS which processes the Disconnect
   and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
   the Dynamic Authorization Client.

   Dynamic Authorization Client (DAC)

   The component which sends Disconnect and CoA-Request packets to the
   Dynamic Authorization Server.  While often residing on the RADIUS
   server, it is also possible for this component to be located on a
   separate host, such as a Rating Engine.

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization Server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client.

De Cnodder, et al.     Expires September 14, 2006               [Page 3]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580
   [RFC2580].

De Cnodder, et al.     Expires September 14, 2006               [Page 4]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

3.  Overview

   "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the
   operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-
   Request, CoA-ACK and CoA-NAK packets.  Typically NAS devices
   implement the DAS function, and thus would be expected to implement
   the RADIUS Dynamic Authorization Server MIB, while DACs implement the
   client function, and thus would be expected to implement the RADIUS
   Dynamic Authorization Client MIB.

   However, it is possible for a RADIUS Dynamic Authorization entity to
   perform both client and server functions.  For example, a RADIUS
   proxy may act as a DAS to one or more DACs, while simultaneously
   acting as a DAC to one or more DASs.  In such situations, it is
   expected that RADIUS entities combining client and server
   functionality will support both the client and server MIBs.

   This memo describes the MIB for Dynamic Authorization Servers and
   relates to the following documents as follows:

   [RFC2618bis] describes the MIB for a RADIUS Auth Client MIB.

   [RFC2619bis] describes the MIB for a RADIUS Auth Server MIB.

   [RFC2620bis] describes the MIB for a RADIUS Acct Client MIB.

   [RFC2621bis] describes the MIB for a RADIUS Acct Server MIB.

   [DYNCLNT] describes the MIB for a RADIUS Dynamic Authorization
   Client.

   A NAS typically implements the MIBs for a RADIUS Authentication
   Client, a RADIUS accounting client, and a RADIUS Dynamic
   Authorization Server.  However, any one MIB can be implemented
   without implementing any of the other MIBs, i.e. the MIBs have no
   dependencies on each other.  A typical case would be for a device to
   implement the MIBs RADIUS authentication server, RADIUS accounting
   server and RADIUS Dynamic Authorization Client.  A RADIUS proxy might
   implement any, all or a subset of the MIBs listed above and the MIB
   as defined in this document.

De Cnodder, et al.     Expires September 14, 2006               [Page 5]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

              +---------------+                      +---------------+
    User 1----|               |  Disconnect-Request  |               |
              |    Dynamic    |     CoA-Request      |    Dynamic    |
    User 2----| Authorization |<---------------------| Authorization |
              |    Server     |--------------------->|    Client     |
    User 3----|     (DAS)     |    Disconnect-Ack    |     (DAC)     |
              |               |    Disconnect-NAK    |               |
              +---------------+    CoA-Ack/CoA-NAK   +---------------+

   Figure 1: Mapping of clients and servers.

   This MIB module for the Dynamic Authorization Server contains the
   following:

   1.  Three scalar objects, and

   2.  One Dynamic Authorization Client Table.  This table contains one
   row for each DAC with which the DAS shares a secret.

De Cnodder, et al.     Expires September 14, 2006               [Page 6]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

4.  RADIUS Dynamic Authorization Server MIB Definitions

   RADIUS-DYNAUTH-SERVER-MIB DEFINITIONS ::= BEGIN

   IMPORTS
          MODULE-IDENTITY, OBJECT-TYPE,
          Counter32, Integer32, mib-2  FROM SNMPv2-SMI  -- [RFC2578]
          SnmpAdminString   FROM SNMP-FRAMEWORK-MIB     -- [RFC3411]
          InetAddressType,
          InetAddress   FROM INET-ADDRESS-MIB           -- [RFC4001]
          MODULE-COMPLIANCE,
          OBJECT-GROUP  FROM SNMPv2-CONF;               -- [RFC2580]

   radiusDynAuthServerMIB MODULE-IDENTITY
          LAST-UPDATED "200603100000Z" -- 10 March 2006
          ORGANIZATION "IETF RADEXT Working Group"
          CONTACT-INFO
                 " Stefaan De Cnodder
                   Alcatel
                   Francis Wellesplein 1
                   B-2018 Antwerp
                   Belgium

                   Phone: +32 3 240 85 15
                   EMail: [email-masked]

                   Nagi Reddy Jonnala
                   Cisco Systems, Inc.
                   Divyasree Chambers, B Wing,
                   O'Shaugnessy Road,
                   Bangalore-560027, India.

                   Phone: +91 98456 99445
                   EMail: [email-masked]

                   Murtaza Chiba
                   Cisco Systems, Inc.
                   170 West Tasman Dr.
                   San Jose CA, 95134

                   Phone: +1 408 525 7198
                   EMail: [email-masked] "
          DESCRIPTION
              "The MIB module for entities implementing the server
               side of the Dynamic Authorization Extensions to Remote
               Authentication Dial In User Service (RADIUS) protocol.

               Copyright (C) The Internet Society (2006).  Initial

De Cnodder, et al.     Expires September 14, 2006               [Page 7]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

               version as published in RFC yyyy;
               for full legal notices see the RFC its"
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

          REVISION "200603100000Z" -- 10 March 2006
          DESCRIPTION "Initial version as published in RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
          ::= { mib-2 xxx }
   -- The value xxx to be assigned by IANA.

   radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
                                         { radiusDynAuthServerMIB 1 }

   radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=
                                  { radiusDynAuthServerMIBObjects 1 }

   radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
         SYNTAX Counter32
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
               "The number of Disconnect-Request packets received from
                unknown addresses. This counter wraps from the maximum
                value to zero and is reset upon system
                (re)initialization."
         ::= { radiusDynAuthServerScalars 1 }

   radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
         SYNTAX Counter32
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
               "The number of CoA-Request packets received from unknown
                addresses. This counter wraps from the maximum value to
                zero and is reset upon system (re)initialization."
         ::= { radiusDynAuthServerScalars 2 }

   radiusDynAuthServerIdentifier OBJECT-TYPE
         SYNTAX SnmpAdminString
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
                "The NAS-Identifier of the RADIUS Dynamic Authorization
                 Server. This is not necessarily the same as sysName in
                 MIB II."
         REFERENCE
                "RFC 2865, Section 5.32, NAS-Identifier."
         ::= { radiusDynAuthServerScalars 3 }

De Cnodder, et al.     Expires September 14, 2006               [Page 8]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

   radiusDynAuthClientTable OBJECT-TYPE
         SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
               "The (conceptual) table listing the RADIUS Dynamic
                Authorization Clients with which the server shares a
                secret."
         ::= { radiusDynAuthServerMIBObjects 2 }

   radiusDynAuthClientEntry OBJECT-TYPE
          SYNTAX     RadiusDynAuthClientEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "An entry (conceptual row) representing one Dynamic
                 Authorization Client with which the server shares a
                 secret."
          INDEX      { radiusDynAuthClientIndex }
          ::= { radiusDynAuthClientTable 1 }

   RadiusDynAuthClientEntry ::= SEQUENCE {
          radiusDynAuthClientIndex                     Integer32,
          radiusDynAuthClientAddressType               InetAddressType,
          radiusDynAuthClientAddress                   InetAddress,
          radiusDynAuthServDisconRequests              Counter32,
          radiusDynAuthServDisconAuthOnlyRequests      Counter32,
          radiusDynAuthServDupDisconRequests           Counter32,
          radiusDynAuthServDisconAcks                  Counter32,
          radiusDynAuthServDisconNaks                  Counter32,
          radiusDynAuthServDisconNakAuthOnlyRequests   Counter32,
          radiusDynAuthServDisconNakSessNoContext      Counter32,
          radiusDynAuthServDisconUserSessRemoved       Counter32,
          radiusDynAuthServMalformedDisconRequests     Counter32,
          radiusDynAuthServDisconBadAuthenticators     Counter32,
          radiusDynAuthServDisconPacketsDropped        Counter32,
          radiusDynAuthServCoARequests                 Counter32,
          radiusDynAuthServCoAAuthOnlyRequests         Counter32,
          radiusDynAuthServDupCoARequests              Counter32,
          radiusDynAuthServCoAAcks                     Counter32,
          radiusDynAuthServCoANaks                     Counter32,
          radiusDynAuthServCoANakAuthOnlyRequests      Counter32,
          radiusDynAuthServCoANakSessNoContext         Counter32,
          radiusDynAuthServCoAUserSessChanged          Counter32,
          radiusDynAuthServMalformedCoARequests        Counter32,
          radiusDynAuthServCoABadAuthenticators        Counter32,
          radiusDynAuthServCoAPacketsDropped           Counter32,
          radiusDynAuthServUnknownTypes                Counter32

De Cnodder, et al.     Expires September 14, 2006               [Page 9]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

   }

   radiusDynAuthClientIndex OBJECT-TYPE
          SYNTAX     Integer32 (1..2147483647)
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "A number uniquely identifying each RADIUS Dynamic
                 Authorization Client with which this Dynamic
                 Authorization Server communicates. This number is
                 allocated by the agent implementing this MIB module,
                 and is unique in this context."
          ::= { radiusDynAuthClientEntry 1 }

   radiusDynAuthClientAddressType OBJECT-TYPE
          SYNTAX     InetAddressType
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The type of IP address of the RADIUS Dynamic
                 Authorization Client referred to in this table entry."
          ::= { radiusDynAuthClientEntry 2 }

   radiusDynAuthClientAddress OBJECT-TYPE
          SYNTAX     InetAddress
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The IP address value of the RADIUS Dynamic
                 Authorization Client referred to in this table entry,
                 using the version neutral IP address format."
          ::= { radiusDynAuthClientEntry 3 }

   radiusDynAuthServDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests received
                 from this Dynamic Authorization Client. This also
                 includes the RADIUS Disconnect-Requests that have a
                 Service-Type attribute with value 'Authorize Only'.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."

De Cnodder, et al.     Expires September 14, 2006              [Page 10]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          ::= { radiusDynAuthClientEntry 4 }

   radiusDynAuthServDisconAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests that include
                 a Service-Type attribute with value 'Authorize Only'
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 5 }

   radiusDynAuthServDupDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of duplicate RADIUS Disconnect-Request
                 packets received from this Dynamic Authorization
                 Client. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 6 }

   radiusDynAuthServDisconAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-ACK packets sent to
                 this Dynamic Authorization Client. This counter wraps
                 from the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 7 }

   radiusDynAuthServDisconNaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"

De Cnodder, et al.     Expires September 14, 2006              [Page 11]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 sent to this Dynamic Authorization Client. This
                 includes the RADIUS Disconnect-NAK packets sent
                 with a Service-Type attribute with value 'Authorize
                 Only' and the RADIUS Disconnect-NAK packets sent
                 because no session context was found. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 8 }

   radiusDynAuthServDisconNakAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets that
                 include a Service-Type attribute with value
                 'Authorize Only' sent to this Dynamic Authorization
                 Client. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 9 }

   radiusDynAuthServDisconNakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 sent to this Dynamic Authorization Client
                 because no session context was found. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 10 }

   radiusDynAuthServDisconUserSessRemoved OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "sessions"

De Cnodder, et al.     Expires September 14, 2006              [Page 12]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of user sessions removed for the
                 Disconnect-Requests received from this
                 Dynamic Authorization Client. Depending on site
                 specific policies, a single Disconnect request
                 can remove multiple user sessions. In the case
                 that this Dynamic Authorization Server has no
                 knowledge of the number of user sessions that
                 are affected by a single request, for each such
                 Disconnect-Request, it will count as a single
                 affected user session only. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 11 }

   radiusDynAuthServMalformedDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS Disconnect-Request
                 packets received from this Dynamic Authorization
                 Client. Bad authenticators and unknown types are not
                 included as malformed Disconnect-Requests. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 12 }

   radiusDynAuthServDisconBadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Request packets
                 which contained invalid Authenticator field
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE

De Cnodder, et al.     Expires September 14, 2006              [Page 13]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 13 }

   radiusDynAuthServDisconPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming Disconnect-Requests
                 from this Dynamic Authorization Client silently
                 discarded by the server application for some reason
                 other than malformed, bad authenticators or unknown
                 types. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 14 }

   radiusDynAuthServCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-requests received from this
                 Dynamic Authorization Client. This also includes
                 the CoA requests that have a Service-Type attribute
                 with value 'Authorize Only'. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 15 }

   radiusDynAuthServCoAAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-requests that include a
                 Service-Type attribute with value 'Authorize Only'
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is

De Cnodder, et al.     Expires September 14, 2006              [Page 14]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 16 }

   radiusDynAuthServDupCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of duplicate RADIUS CoA-Request packets
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 17 }

   radiusDynAuthServCoAAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-ACK packets sent to this
                 Dynamic Authorization Client. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 18 }

   radiusDynAuthServCoANaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets sent to
                 this Dynamic Authorization Client. This includes
                 the RADIUS CoA-NAK packets sent with a Service-Type
                 attribute with value 'Authorize Only' and the RADIUS
                 CoA-NAK packets sent because no session context was

De Cnodder, et al.     Expires September 14, 2006              [Page 15]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 found. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 19 }

   radiusDynAuthServCoANakAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets that include a
                 Service-Type attribute with value 'Authorize Only'
                 sent to this Dynamic Authorization Client. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 20 }

   radiusDynAuthServCoANakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets sent to this
                 Dynamic Authorization Client because no session context
                 was found. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 21 }

   radiusDynAuthServCoAUserSessChanged OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "sessions"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of user sessions authorization
                 changed for the CoA-Requests received from this
                 Dynamic Authorization Client. Depending on site
                 specific policies, a single CoA request can change

De Cnodder, et al.     Expires September 14, 2006              [Page 16]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 multiple user sessions' authorization.  In the case
                 this Dynamic Authorization Server has no knowledge of
                 the number of user sessions that are affected by a
                 single request, for each such CoA-Request, it will
                 count as a single affected user session only. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 22 }

   radiusDynAuthServMalformedCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS CoA-Request packets
                 received from this Dynamic Authorization Client. Bad
                 authenticators and unknown types are not included as
                 malformed CoA-Requests. This counter wraps from the
                 maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry  23 }

   radiusDynAuthServCoABadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-Request packets which
                 contained invalid Authenticator field received
                 from this Dynamic Authorization Client. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 24 }

   radiusDynAuthServCoAPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"

De Cnodder, et al.     Expires September 14, 2006              [Page 17]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming CoA packets from this
                 Dynamic Authorization Client silently discarded
                 by the server application for some reason other than
                 malformed, bad authenticators or unknown types. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 25 }

   radiusDynAuthServUnknownTypes OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming packets of unknown types which
                 were received on the Dynamic Authorization port. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 26 }

   -- conformance information

   radiusDynAuthServerMIBConformance
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 2 }
   radiusDynAuthServerMIBCompliances
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 1 }
   radiusDynAuthServerMIBGroups
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 2 }

   -- compliance statements

   radiusAuthServerMIBCompliance MODULE-COMPLIANCE
          STATUS  current
          DESCRIPTION
                "The compliance statement for entities implementing
                 the RADIUS Dynamic Authorization Server."
          MODULE  -- this module
          MANDATORY-GROUPS { radiusDynAuthServerMIBGroup }

          GROUP              radiusDynAuthServerAuthOnlyGroup

De Cnodder, et al.     Expires September 14, 2006              [Page 18]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          DESCRIPTION
                "Only required for Dynamic Authorization Clients that
                 are supporting Service-Type attributes with value
                 'Authorize-Only'."

          GROUP              radiusDynAuthServerNoSessGroup
          DESCRIPTION
                "This group is not required in case the Dynamic
                 Authorization Server can not easily determine whether
                 a session exists or not (e.g., in case of a RADIUS
                 proxy)."

          ::= { radiusDynAuthServerMIBCompliances 1 }

   -- units of conformance

   radiusDynAuthServerMIBGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthServerDisconInvalidClientAddresses,
                    radiusDynAuthServerCoAInvalidClientAddresses,
                    radiusDynAuthServerIdentifier,
                    radiusDynAuthClientAddressType,
                    radiusDynAuthClientAddress,
                    radiusDynAuthServDisconRequests,
                    radiusDynAuthServDupDisconRequests,
                    radiusDynAuthServDisconAcks,
                    radiusDynAuthServDisconNaks,
                    radiusDynAuthServDisconUserSessRemoved,
                    radiusDynAuthServMalformedDisconRequests,
                    radiusDynAuthServDisconBadAuthenticators,
                    radiusDynAuthServDisconPacketsDropped,
                    radiusDynAuthServCoARequests,
                    radiusDynAuthServDupCoARequests,
                    radiusDynAuthServCoAAcks,
                    radiusDynAuthServCoANaks,
                    radiusDynAuthServCoAUserSessChanged,
                    radiusDynAuthServMalformedCoARequests,
                    radiusDynAuthServCoABadAuthenticators,
                    radiusDynAuthServCoAPacketsDropped,
                    radiusDynAuthServUnknownTypes
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects providing management of
                 a RADIUS Dynamic Authorization Server."
          ::= { radiusDynAuthServerMIBGroups 1 }

   radiusDynAuthServerAuthOnlyGroup OBJECT-GROUP

De Cnodder, et al.     Expires September 14, 2006              [Page 19]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          OBJECTS { radiusDynAuthServDisconAuthOnlyRequests,
                    radiusDynAuthServDisconNakAuthOnlyRequests,
                    radiusDynAuthServCoAAuthOnlyRequests,
                    radiusDynAuthServCoANakAuthOnlyRequests
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages including Service-Type attribute with
                 value 'Authorize Only'."
          ::= { radiusDynAuthServerMIBGroups 2 }

   radiusDynAuthServerNoSessGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthServDisconNakSessNoContext,
                    radiusDynAuthServCoANakSessNoContext
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages that are referring to non existing sessions."
          ::= { radiusDynAuthServerMIBGroups 3 }

   END

De Cnodder, et al.     Expires September 14, 2006              [Page 20]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

5.  Security Considerations

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   radiusDynAuthClientAddress and radiusDynAuthClientAddressType

   These can be used to determine the address of the DAC with which the
   DAS is communicating.  This information could be useful in mounting
   an attack on the DAC.

   radiusDynAuthServerIdentifier

   This can be used to determine the Identifier of the DAS.  This
   information could be useful in impersonating the DAS.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

De Cnodder, et al.     Expires September 14, 2006              [Page 21]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

6.  IANA considerations

   IANA is requested to assign an OID xxx under mib-2.

De Cnodder, et al.     Expires September 14, 2006              [Page 22]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

7.  Acknowledgements

   The authors would also like to acknowledge the following people for
   their comments on this document: Bernard Aboba, Alan DeKok, David
   Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg
   Weber, Bert Wijnen, and Glen Zorn.

De Cnodder, et al.     Expires September 14, 2006              [Page 23]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Structure of Management
              Information Version 2 (SMIv2)", STD 58, RFC 2578,
              April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Textual Conventions for
              SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Conformance Statements for
              SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC4001]  Daniele, M. and et al., "Textual Conventions for Internet
              Network Addresses", RFC 4001, February 2005.

8.2.  Informative References

   [DYNCLNT]  De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic
              Authorization Client MIB",
              draft-ietf-radext-dynauth-client-mib-03.txt, work in
              progress, December 2005.

   [RFC2618bis]
              Nelson, D., "RADIUS Auth Client MIB (IPv6)",
              draft-ietf-radext-rfc2618bis-01.txt work in progress,
              October 2005.

   [RFC2619bis]
              Nelson, D., "RADIUS Auth Server MIB (IPv6)",
              draft-ietf-radext-rfc2619bis-01.txt work in progress,

De Cnodder, et al.     Expires September 14, 2006              [Page 24]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

              October 2005.

   [RFC2620bis]
              Nelson, D., "RADIUS Acct Client MIB (IPv6)",
              draft-ietf-radext-rfc2620bis-01.txt work in progress,
              October 2005.

   [RFC2621bis]
              Nelson, D., "RADIUS Acct Server MIB (IPv6)",
              draft-ietf-radext-rfc2621bis-01.txt work in progress,
              October 2005.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

De Cnodder, et al.     Expires September 14, 2006              [Page 25]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Authors' Addresses

   Stefaan De Cnodder
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerp
   Belgium

   Phone: +32 3 240 85 15
   Email: [email-masked]

   Nagi Reddy Jonnala
   Cisco Systems, Inc.
   Divyasree Chambers,  B Wing, O'Shaugnessy Road
   Bangalore-560027, India

   Phone: +91 98456 99445
   Email: [email-masked]

   Murtaza Chiba
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose CA, 95134

   Phone: +1 408 525 7198
   Email: [email-masked]

De Cnodder, et al.     Expires September 14, 2006              [Page 26]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

De Cnodder, et al.     Expires September 14, 2006              [Page 27]


--------------060703020402050606000906
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
 name="draft-ietf-radext-dynauth-server-mib-04.txt"
Content-Disposition: inline;
 filename="draft-ietf-radext-dynauth-server-mib-04.txt"

Network Working Group                                      S. De Cnodder
Internet-Draft                                                   Alcatel
Expires: September 14, 2006                                   N. Jonnala
                                                                M. Chiba
                                                     Cisco Systems, Inc.
                                                          March 13, 2006

                    Dynamic Authorization Server MIB
              draft-ietf-radext-dynauth-server-mib-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
   functions that support the dynamic authorization extensions as
   defined in RFC 3576.

De Cnodder, et al.     Expires September 14, 2006               [Page 1]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  RADIUS Dynamic Authorization Server MIB Definitions  . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

De Cnodder, et al.     Expires September 14, 2006               [Page 2]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   It is becoming increasingly important to support Dynamic
   Authorization extensions on the network access server (NAS) devices
   to handle the Disconnect and Change-of-Authorization (CoA) messages
   as described in [RFC3576].  As a result, the effective management of
   RADIUS Dynamic Authorization entities is of considerable importance.
   This RADIUS Dynamic Authorization Server (DAS) MIB complements the
   managed objects used for managing RADIUS authentication and
   accounting clients as described in [RFC2618bis] and [RFC2620bis],
   respectively.

   -- RFC Ed.: references [DYNSERV], [RFC2618bis], [RFC2619bis],
   --          [RFC2620bis], and [RFC2621bis] should be replaced by
   --          references to the corresponding RFC.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS which processes the Disconnect
   and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
   the Dynamic Authorization Client.

   Dynamic Authorization Client (DAC)

   The component which sends Disconnect and CoA-Request packets to the
   Dynamic Authorization Server.  While often residing on the RADIUS
   server, it is also possible for this component to be located on a
   separate host, such as a Rating Engine.

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization Server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client.

De Cnodder, et al.     Expires September 14, 2006               [Page 3]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580
   [RFC2580].

De Cnodder, et al.     Expires September 14, 2006               [Page 4]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

3.  Overview

   "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the
   operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-
   Request, CoA-ACK and CoA-NAK packets.  Typically NAS devices
   implement the DAS function, and thus would be expected to implement
   the RADIUS Dynamic Authorization Server MIB, while DACs implement the
   client function, and thus would be expected to implement the RADIUS
   Dynamic Authorization Client MIB.

   However, it is possible for a RADIUS Dynamic Authorization entity to
   perform both client and server functions.  For example, a RADIUS
   proxy may act as a DAS to one or more DACs, while simultaneously
   acting as a DAC to one or more DASs.  In such situations, it is
   expected that RADIUS entities combining client and server
   functionality will support both the client and server MIBs.

   This memo describes the MIB for Dynamic Authorization Servers and
   relates to the following documents as follows:

   [RFC2618bis] describes the MIB for a RADIUS Auth Client MIB.

   [RFC2619bis] describes the MIB for a RADIUS Auth Server MIB.

   [RFC2620bis] describes the MIB for a RADIUS Acct Client MIB.

   [RFC2621bis] describes the MIB for a RADIUS Acct Server MIB.

   [DYNCLNT] describes the MIB for a RADIUS Dynamic Authorization
   Client.

   A NAS typically implements the MIBs for a RADIUS Authentication
   Client, a RADIUS accounting client, and a RADIUS Dynamic
   Authorization Server.  However, any one MIB can be implemented
   without implementing any of the other MIBs, i.e. the MIBs have no
   dependencies on each other.  A typical case would be for a device to
   implement the MIBs RADIUS authentication server, RADIUS accounting
   server and RADIUS Dynamic Authorization Client.  A RADIUS proxy might
   implement any, all or a subset of the MIBs listed above and the MIB
   as defined in this document.

De Cnodder, et al.     Expires September 14, 2006               [Page 5]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

              +---------------+                      +---------------+
    User 1----|               |  Disconnect-Request  |               |
              |    Dynamic    |     CoA-Request      |    Dynamic    |
    User 2----| Authorization |<---------------------| Authorization |
              |    Server     |--------------------->|    Client     |
    User 3----|     (DAS)     |    Disconnect-Ack    |     (DAC)     |
              |               |    Disconnect-NAK    |               |
              +---------------+    CoA-Ack/CoA-NAK   +---------------+

   Figure 1: Mapping of clients and servers.

   This MIB module for the Dynamic Authorization Server contains the
   following:

   1.  Three scalar objects, and

   2.  One Dynamic Authorization Client Table.  This table contains one
   row for each DAC with which the DAS shares a secret.

De Cnodder, et al.     Expires September 14, 2006               [Page 6]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

4.  RADIUS Dynamic Authorization Server MIB Definitions

   RADIUS-DYNAUTH-SERVER-MIB DEFINITIONS ::= BEGIN

   IMPORTS
          MODULE-IDENTITY, OBJECT-TYPE,
          Counter32, Integer32, mib-2  FROM SNMPv2-SMI  -- [RFC2578]
          SnmpAdminString   FROM SNMP-FRAMEWORK-MIB     -- [RFC3411]
          InetAddressType,
          InetAddress   FROM INET-ADDRESS-MIB           -- [RFC4001]
          MODULE-COMPLIANCE,
          OBJECT-GROUP  FROM SNMPv2-CONF;               -- [RFC2580]

   radiusDynAuthServerMIB MODULE-IDENTITY
          LAST-UPDATED "200603100000Z" -- 10 March 2006
          ORGANIZATION "IETF RADEXT Working Group"
          CONTACT-INFO
                 " Stefaan De Cnodder
                   Alcatel
                   Francis Wellesplein 1
                   B-2018 Antwerp
                   Belgium

                   Phone: +32 3 240 85 15
                   EMail: [email-masked]

                   Nagi Reddy Jonnala
                   Cisco Systems, Inc.
                   Divyasree Chambers, B Wing,
                   O'Shaugnessy Road,
                   Bangalore-560027, India.

                   Phone: +91 98456 99445
                   EMail: [email-masked]

                   Murtaza Chiba
                   Cisco Systems, Inc.
                   170 West Tasman Dr.
                   San Jose CA, 95134

                   Phone: +1 408 525 7198
                   EMail: [email-masked] "
          DESCRIPTION
              "The MIB module for entities implementing the server
               side of the Dynamic Authorization Extensions to Remote
               Authentication Dial In User Service (RADIUS) protocol.

               Copyright (C) The Internet Society (2006).  Initial

De Cnodder, et al.     Expires September 14, 2006               [Page 7]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

               version as published in RFC yyyy;
               for full legal notices see the RFC its"
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

          REVISION "200603100000Z" -- 10 March 2006
          DESCRIPTION "Initial version as published in RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
          ::= { mib-2 xxx }
   -- The value xxx to be assigned by IANA.

   radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
                                         { radiusDynAuthServerMIB 1 }

   radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=
                                  { radiusDynAuthServerMIBObjects 1 }

   radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
         SYNTAX Counter32
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
               "The number of Disconnect-Request packets received from
                unknown addresses. This counter wraps from the maximum
                value to zero and is reset upon system
                (re)initialization."
         ::= { radiusDynAuthServerScalars 1 }

   radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
         SYNTAX Counter32
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
               "The number of CoA-Request packets received from unknown
                addresses. This counter wraps from the maximum value to
                zero and is reset upon system (re)initialization."
         ::= { radiusDynAuthServerScalars 2 }

   radiusDynAuthServerIdentifier OBJECT-TYPE
         SYNTAX SnmpAdminString
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
                "The NAS-Identifier of the RADIUS Dynamic Authorization
                 Server. This is not necessarily the same as sysName in
                 MIB II."
         REFERENCE
                "RFC 2865, Section 5.32, NAS-Identifier."
         ::= { radiusDynAuthServerScalars 3 }

De Cnodder, et al.     Expires September 14, 2006               [Page 8]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

   radiusDynAuthClientTable OBJECT-TYPE
         SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
               "The (conceptual) table listing the RADIUS Dynamic
                Authorization Clients with which the server shares a
                secret."
         ::= { radiusDynAuthServerMIBObjects 2 }

   radiusDynAuthClientEntry OBJECT-TYPE
          SYNTAX     RadiusDynAuthClientEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "An entry (conceptual row) representing one Dynamic
                 Authorization Client with which the server shares a
                 secret."
          INDEX      { radiusDynAuthClientIndex }
          ::= { radiusDynAuthClientTable 1 }

   RadiusDynAuthClientEntry ::= SEQUENCE {
          radiusDynAuthClientIndex                     Integer32,
          radiusDynAuthClientAddressType               InetAddressType,
          radiusDynAuthClientAddress                   InetAddress,
          radiusDynAuthServDisconRequests              Counter32,
          radiusDynAuthServDisconAuthOnlyRequests      Counter32,
          radiusDynAuthServDupDisconRequests           Counter32,
          radiusDynAuthServDisconAcks                  Counter32,
          radiusDynAuthServDisconNaks                  Counter32,
          radiusDynAuthServDisconNakAuthOnlyRequests   Counter32,
          radiusDynAuthServDisconNakSessNoContext      Counter32,
          radiusDynAuthServDisconUserSessRemoved       Counter32,
          radiusDynAuthServMalformedDisconRequests     Counter32,
          radiusDynAuthServDisconBadAuthenticators     Counter32,
          radiusDynAuthServDisconPacketsDropped        Counter32,
          radiusDynAuthServCoARequests                 Counter32,
          radiusDynAuthServCoAAuthOnlyRequests         Counter32,
          radiusDynAuthServDupCoARequests              Counter32,
          radiusDynAuthServCoAAcks                     Counter32,
          radiusDynAuthServCoANaks                     Counter32,
          radiusDynAuthServCoANakAuthOnlyRequests      Counter32,
          radiusDynAuthServCoANakSessNoContext         Counter32,
          radiusDynAuthServCoAUserSessChanged          Counter32,
          radiusDynAuthServMalformedCoARequests        Counter32,
          radiusDynAuthServCoABadAuthenticators        Counter32,
          radiusDynAuthServCoAPacketsDropped           Counter32,
          radiusDynAuthServUnknownTypes                Counter32

De Cnodder, et al.     Expires September 14, 2006               [Page 9]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

   }

   radiusDynAuthClientIndex OBJECT-TYPE
          SYNTAX     Integer32 (1..2147483647)
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                "A number uniquely identifying each RADIUS Dynamic
                 Authorization Client with which this Dynamic
                 Authorization Server communicates. This number is
                 allocated by the agent implementing this MIB module,
                 and is unique in this context."
          ::= { radiusDynAuthClientEntry 1 }

   radiusDynAuthClientAddressType OBJECT-TYPE
          SYNTAX     InetAddressType
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The type of IP address of the RADIUS Dynamic
                 Authorization Client referred to in this table entry."
          ::= { radiusDynAuthClientEntry 2 }

   radiusDynAuthClientAddress OBJECT-TYPE
          SYNTAX     InetAddress
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The IP address value of the RADIUS Dynamic
                 Authorization Client referred to in this table entry,
                 using the version neutral IP address format."
          ::= { radiusDynAuthClientEntry 3 }

   radiusDynAuthServDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests received
                 from this Dynamic Authorization Client. This also
                 includes the RADIUS Disconnect-Requests that have a
                 Service-Type attribute with value 'Authorize Only'.
                 This counter wraps from the maximum value to zero and
                 is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."

De Cnodder, et al.     Expires September 14, 2006              [Page 10]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          ::= { radiusDynAuthClientEntry 4 }

   radiusDynAuthServDisconAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Requests that include
                 a Service-Type attribute with value 'Authorize Only'
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 5 }

   radiusDynAuthServDupDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of duplicate RADIUS Disconnect-Request
                 packets received from this Dynamic Authorization
                 Client. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 6 }

   radiusDynAuthServDisconAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-ACK packets sent to
                 this Dynamic Authorization Client. This counter wraps
                 from the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 7 }

   radiusDynAuthServDisconNaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"

De Cnodder, et al.     Expires September 14, 2006              [Page 11]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 sent to this Dynamic Authorization Client. This
                 includes the RADIUS Disconnect-NAK packets sent
                 with a Service-Type attribute with value 'Authorize
                 Only' and the RADIUS Disconnect-NAK packets sent
                 because no session context was found. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 8 }

   radiusDynAuthServDisconNakAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets that
                 include a Service-Type attribute with value
                 'Authorize Only' sent to this Dynamic Authorization
                 Client. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 9 }

   radiusDynAuthServDisconNakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-NAK packets
                 sent to this Dynamic Authorization Client
                 because no session context was found. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 10 }

   radiusDynAuthServDisconUserSessRemoved OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "sessions"

De Cnodder, et al.     Expires September 14, 2006              [Page 12]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of user sessions removed for the
                 Disconnect-Requests received from this
                 Dynamic Authorization Client. Depending on site
                 specific policies, a single Disconnect request
                 can remove multiple user sessions. In the case
                 that this Dynamic Authorization Server has no
                 knowledge of the number of user sessions that
                 are affected by a single request, for each such
                 Disconnect-Request, it will count as a single
                 affected user session only. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM)."
          ::= { radiusDynAuthClientEntry 11 }

   radiusDynAuthServMalformedDisconRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS Disconnect-Request
                 packets received from this Dynamic Authorization
                 Client. Bad authenticators and unknown types are not
                 included as malformed Disconnect-Requests. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 12 }

   radiusDynAuthServDisconBadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS Disconnect-Request packets
                 which contained invalid Authenticator field
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE

De Cnodder, et al.     Expires September 14, 2006              [Page 13]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 13 }

   radiusDynAuthServDisconPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming Disconnect-Requests
                 from this Dynamic Authorization Client silently
                 discarded by the server application for some reason
                 other than malformed, bad authenticators or unknown
                 types. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.1, Disconnect Messages (DM), and
                 Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 14 }

   radiusDynAuthServCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-requests received from this
                 Dynamic Authorization Client. This also includes
                 the CoA requests that have a Service-Type attribute
                 with value 'Authorize Only'. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 15 }

   radiusDynAuthServCoAAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-requests that include a
                 Service-Type attribute with value 'Authorize Only'
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is

De Cnodder, et al.     Expires September 14, 2006              [Page 14]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 16 }

   radiusDynAuthServDupCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of duplicate RADIUS CoA-Request packets
                 received from this Dynamic Authorization Client. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 17 }

   radiusDynAuthServCoAAcks  OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-ACK packets sent to this
                 Dynamic Authorization Client. This counter wraps from
                 the maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 18 }

   radiusDynAuthServCoANaks OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets sent to
                 this Dynamic Authorization Client. This includes
                 the RADIUS CoA-NAK packets sent with a Service-Type
                 attribute with value 'Authorize Only' and the RADIUS
                 CoA-NAK packets sent because no session context was

De Cnodder, et al.     Expires September 14, 2006              [Page 15]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 found. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 19 }

   radiusDynAuthServCoANakAuthOnlyRequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets that include a
                 Service-Type attribute with value 'Authorize Only'
                 sent to this Dynamic Authorization Client. This counter
                 wraps from the maximum value to zero and is reset upon
                 system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 20 }

   radiusDynAuthServCoANakSessNoContext OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "replies"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-NAK packets sent to this
                 Dynamic Authorization Client because no session context
                 was found. This counter wraps from the maximum value to
                 zero and is reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 21 }

   radiusDynAuthServCoAUserSessChanged OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "sessions"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of user sessions authorization
                 changed for the CoA-Requests received from this
                 Dynamic Authorization Client. Depending on site
                 specific policies, a single CoA request can change

De Cnodder, et al.     Expires September 14, 2006              [Page 16]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

                 multiple user sessions' authorization.  In the case
                 this Dynamic Authorization Server has no knowledge of
                 the number of user sessions that are affected by a
                 single request, for each such CoA-Request, it will
                 count as a single affected user session only. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA)."
          ::= { radiusDynAuthClientEntry 22 }

   radiusDynAuthServMalformedCoARequests OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of malformed RADIUS CoA-Request packets
                 received from this Dynamic Authorization Client. Bad
                 authenticators and unknown types are not included as
                 malformed CoA-Requests. This counter wraps from the
                 maximum value to zero and is reset upon system
                 (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry  23 }

   radiusDynAuthServCoABadAuthenticators OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of RADIUS CoA-Request packets which
                 contained invalid Authenticator field received
                 from this Dynamic Authorization Client. This counter
                 wraps from the maximum value to zero and is reset
                 upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 24 }

   radiusDynAuthServCoAPacketsDropped OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"

De Cnodder, et al.     Expires September 14, 2006              [Page 17]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming CoA packets from this
                 Dynamic Authorization Client silently discarded
                 by the server application for some reason other than
                 malformed, bad authenticators or unknown types. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.2, Change-of-Authorization
                 Messages (CoA), and Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 25 }

   radiusDynAuthServUnknownTypes OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "requests"
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The number of incoming packets of unknown types which
                 were received on the Dynamic Authorization port. This
                 counter wraps from the maximum value to zero and is
                 reset upon system (re)initialization."
          REFERENCE
                "RFC 3576, Section 2.3, Packet Format."
          ::= { radiusDynAuthClientEntry 26 }

   -- conformance information

   radiusDynAuthServerMIBConformance
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 2 }
   radiusDynAuthServerMIBCompliances
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 1 }
   radiusDynAuthServerMIBGroups
          OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 2 }

   -- compliance statements

   radiusAuthServerMIBCompliance MODULE-COMPLIANCE
          STATUS  current
          DESCRIPTION
                "The compliance statement for entities implementing
                 the RADIUS Dynamic Authorization Server."
          MODULE  -- this module
          MANDATORY-GROUPS { radiusDynAuthServerMIBGroup }

          GROUP              radiusDynAuthServerAuthOnlyGroup

De Cnodder, et al.     Expires September 14, 2006              [Page 18]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          DESCRIPTION
                "Only required for Dynamic Authorization Clients that
                 are supporting Service-Type attributes with value
                 'Authorize-Only'."

          GROUP              radiusDynAuthServerNoSessGroup
          DESCRIPTION
                "This group is not required in case the Dynamic
                 Authorization Server can not easily determine whether
                 a session exists or not (e.g., in case of a RADIUS
                 proxy)."

          ::= { radiusDynAuthServerMIBCompliances 1 }

   -- units of conformance

   radiusDynAuthServerMIBGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthServerDisconInvalidClientAddresses,
                    radiusDynAuthServerCoAInvalidClientAddresses,
                    radiusDynAuthServerIdentifier,
                    radiusDynAuthClientAddressType,
                    radiusDynAuthClientAddress,
                    radiusDynAuthServDisconRequests,
                    radiusDynAuthServDupDisconRequests,
                    radiusDynAuthServDisconAcks,
                    radiusDynAuthServDisconNaks,
                    radiusDynAuthServDisconUserSessRemoved,
                    radiusDynAuthServMalformedDisconRequests,
                    radiusDynAuthServDisconBadAuthenticators,
                    radiusDynAuthServDisconPacketsDropped,
                    radiusDynAuthServCoARequests,
                    radiusDynAuthServDupCoARequests,
                    radiusDynAuthServCoAAcks,
                    radiusDynAuthServCoANaks,
                    radiusDynAuthServCoAUserSessChanged,
                    radiusDynAuthServMalformedCoARequests,
                    radiusDynAuthServCoABadAuthenticators,
                    radiusDynAuthServCoAPacketsDropped,
                    radiusDynAuthServUnknownTypes
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects providing management of
                 a RADIUS Dynamic Authorization Server."
          ::= { radiusDynAuthServerMIBGroups 1 }

   radiusDynAuthServerAuthOnlyGroup OBJECT-GROUP

De Cnodder, et al.     Expires September 14, 2006              [Page 19]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

          OBJECTS { radiusDynAuthServDisconAuthOnlyRequests,
                    radiusDynAuthServDisconNakAuthOnlyRequests,
                    radiusDynAuthServCoAAuthOnlyRequests,
                    radiusDynAuthServCoANakAuthOnlyRequests
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages including Service-Type attribute with
                 value 'Authorize Only'."
          ::= { radiusDynAuthServerMIBGroups 2 }

   radiusDynAuthServerNoSessGroup OBJECT-GROUP
          OBJECTS { radiusDynAuthServDisconNakSessNoContext,
                    radiusDynAuthServCoANakSessNoContext
                  }
          STATUS  current
          DESCRIPTION
                "The collection of objects supporting the RADIUS
                 messages that are referring to non existing sessions."
          ::= { radiusDynAuthServerMIBGroups 3 }

   END

De Cnodder, et al.     Expires September 14, 2006              [Page 20]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

5.  Security Considerations

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   radiusDynAuthClientAddress and radiusDynAuthClientAddressType

   These can be used to determine the address of the DAC with which the
   DAS is communicating.  This information could be useful in mounting
   an attack on the DAC.

   radiusDynAuthServerIdentifier

   This can be used to determine the Identifier of the DAS.  This
   information could be useful in impersonating the DAS.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

De Cnodder, et al.     Expires September 14, 2006              [Page 21]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

6.  IANA considerations

   IANA is requested to assign an OID xxx under mib-2.

De Cnodder, et al.     Expires September 14, 2006              [Page 22]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

7.  Acknowledgements

   The authors would also like to acknowledge the following people for
   their comments on this document: Bernard Aboba, Alan DeKok, David
   Nelson, Anjaneyulu Pata, Dan Romascanu, Greg Weber, Bert Wijnen, and
   Glen Zorn.

De Cnodder, et al.     Expires September 14, 2006              [Page 23]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Structure of Management
              Information Version 2 (SMIv2)", STD 58, RFC 2578,
              April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Textual Conventions for
              SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              Rose, M., and S. Waldbusser, "Conformance Statements for
              SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC4001]  Daniele, M. and et al., "Textual Conventions for Internet
              Network Addresses", RFC 4001, February 2005.

8.2.  Informative References

   [DYNCLNT]  De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic
              Authorization Client MIB",
              draft-ietf-radext-dynauth-client-mib-03.txt, work in
              progress, December 2005.

   [RFC2618bis]
              Nelson, D., "RADIUS Auth Client MIB (IPv6)",
              draft-ietf-radext-rfc2618bis-01.txt work in progress,
              October 2005.

   [RFC2619bis]
              Nelson, D., "RADIUS Auth Server MIB (IPv6)",
              draft-ietf-radext-rfc2619bis-01.txt work in progress,

De Cnodder, et al.     Expires September 14, 2006              [Page 24]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

              October 2005.

   [RFC2620bis]
              Nelson, D., "RADIUS Acct Client MIB (IPv6)",
              draft-ietf-radext-rfc2620bis-01.txt work in progress,
              October 2005.

   [RFC2621bis]
              Nelson, D., "RADIUS Acct Server MIB (IPv6)",
              draft-ietf-radext-rfc2621bis-01.txt work in progress,
              October 2005.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

De Cnodder, et al.     Expires September 14, 2006              [Page 25]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Authors' Addresses

   Stefaan De Cnodder
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerp
   Belgium

   Phone: +32 3 240 85 15
   Email: [email-masked]

   Nagi Reddy Jonnala
   Cisco Systems, Inc.
   Divyasree Chambers,  B Wing, O'Shaugnessy Road
   Bangalore-560027, India

   Phone: +91 98456 99445
   Email: [email-masked]

   Murtaza Chiba
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose CA, 95134

   Phone: +1 408 525 7198
   Email: [email-masked]

De Cnodder, et al.     Expires September 14, 2006              [Page 26]

Internet-Draft      Dynamic Authorization Server MIB          March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

De Cnodder, et al.     Expires September 14, 2006              [Page 27]


--------------060703020402050606000906--

--
to unsubscribe send a message 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, 13 Mar 2006 20:36:48 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 13 Mar 2006 15:36:28 -0500
From: "Nelson, David" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>
Cc: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bert writes...

> I am happy to chekc a pre-release rev 04 as well.

> > Stefaan DeCnodder writes...
> >
> > Since the suggestion has sufficient support it is best to
> > do so. Is it Ok to sent a version -04 of both docs after the=20
> > IETF containing all updates?

I think Bert would like to get this document revision submitted ASAP.
The IETF I-D Tracker tool has these documents in the "Revised I-D
Required" state.

Bert will be stepping down as O&M Area Director after IETF-65, so if
these documents are still awaiting IESG approval after next week, then
they will need to be handed off to another AD for shepherding.

-- Dave

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

Delivery-date: Mon, 13 Mar 2006 19:16:53 +0000
Content-class: urn:content-classes:message
Subject: Submission of presentations (slides) for the RADEXT WG session at  IETF-65
Date: Mon, 13 Mar 2006 14:16:14 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>

The chairs (of all WGs) have been requested to post WG session =
presentation materials on the web (at =
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
5
) in advance of the meeting.  This is especially important to assist =
remote participants (via streaming audio and jabber).  The chairs now =
have a nice web-based tool to publish WG materials, agendas, etc., =
without assistance from the Secretariat.

Please submit your RADEXT WG presentation materials to the chairs ASAP.  =
We would *really* like to have them all posted prior to the RADEXT =
session on Tuesday morning of IETF week.

Regards,
=A0
Dave & Bernard

--
to unsubscribe send a message 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, 11 Mar 2006 01:34:15 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Fri, 10 Mar 2006 20:33:46 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>
Cc: <[email-masked]>

=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Emile van Bergen
> Sent: Thursday, March 09, 2006 5:43 AM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6=20
> Prefix Attribute"
>=20
<snip>
> The current Extended Attribute draft uses the DIAMETER=20
> format, and the only facility it has toward structured=20
> data is the 'Grouped' data type, which is a *blank*=20
> container for *top level* attributes only.
<snip>

Hi Emile,
I just wanted to make sure we are in sync on this bit
above.  In RFC 3588, I see:

4.4.  Grouped AVP Values

   The Diameter protocol allows AVP values of type 'Grouped.'  This
   implies that the Data field is actually a sequence of AVPs.  It is
   possible to include an AVP with a Grouped type within a Grouped type,
   that is, to nest them.  [...]

Doesn't this ability to nest Grouped AVPs effectively
provide a c-struct like facility that enables arbitrary
complexity? =20

I wasn't sure if by *top level*, you meant non-recursive
grouping, or if you meant all layers are defined in the
same attribute type space (I think the latter is probably
a good thing).

Greg

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

Envelope-to: [email-masked]
Delivery-date: Fri, 10 Mar 2006 18:40:51 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") 
cc: [email-masked]
Date: Fri, 10 Mar 2006 13:47:39 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> It would seem to me that if the RADIUS protocol engine
> doesn't "care" about the member elements, it does not need to know their
> boundaries.  Hence we are back to the opaque blob.  If it *does* need to
> know the boundaries, then I claim that it "cares" about the data
> elements.

  Agreed.

> Now, I suppose we could attempt to define "levels of caring".  For
> example, in the RADIUS/GEOPRIV draft, there are attributes that contain
> a number of data elements, that when reassembled form a GEOPRIV data
> structure.  Is it necessary for the RADIUS protocol engine to know their
> boundaries?

  If not, then the boundaries may not need to be described in the
RADIUS document.  A simple normitive reference to the geopriv document
containing the structure definition would be fine.  (It would be nice
for the geopriv authors to respond to comments about their document).

> I personally object to the notion of RADIUS as a packager and shipper
> for arbitrary applications, i.e. RADIUS as transport mechanism.  I
> realize that it has been, and continues to be, used in this fashion,
> usually for applications at least vaguely related to AAA.

  As more protocols need AAA features, the boundaries between
protocols start to blur.  This is unfortunate, but it's happening.

> I think the argument that RADIUS cares "enough" about the individual
> data elements to warrant defining them in explicit sub-fields of a
> RADIUS attribute, but not so much as to require any regularization of
> their on-the-wire encoding, is problematic.

  Agreed.  The practice should be discouraged.  Normitive references
to other standards that describe the sub-fields would be the preferred
approach.

> The only scenario that I see that justifies this middle-ground
> "level of caring" is the RADIUS as transport case, i.e. the UPS
> Store model.

  And I think those situations are few and far between.

  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, 10 Mar 2006 15:27:10 +0000
Content-class: urn:content-classes:message
Subject: WG Process Issues (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
Date: Fri, 10 Mar 2006 10:26:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> This is clearly not the way this WG works, though (just one=20
> example: the 802 draft which emerged horribly broken from the
> design team & was funneled directly into last call).

Whether the draft was "horribly" broken is a value judgment.  You have
accurately observed one item of process that, in RADEXT at least, is
different from the traditional IETF of years past.  Working Group Last
Call (WGLC) is used more aggressively these days, and is not always the
"last" opportunity for the WG to comment.  Sometimes WGLC is in reality
Working Group First Call.  The fact of the matter is that the chairs
have noticed that it is often difficult to get a broad cross section of
the WG to actively comment on drafts until they are in WGLC.  I suspect
that other WGs have seen this, as well.

> I consider the position of WG chair to be a service position, with the
> major responsibility that (fraught with danger!) of gauging WG
consensus.

This is still a major responsibility.  It is not the only one however.
Among the additional responsibilities, the chairs are held accountable
by the ADs for adherence to WG milestones and charters, and for the
overall quality level of documents that the WG sends to the 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: Fri, 10 Mar 2006 15:10:18 +0000
Content-class: urn:content-classes:message
Subject: Dealing with compound attributes (was RE: RADEXT WG Last Call on  "RADIUS Delegated IPv6 Prefix Attribute")
Date: Fri, 10 Mar 2006 10:10:04 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

I've changed the topic (again) because I think we've wandered past
discussion of a particular draft in WGLC, and are effectively discussing
the RADIUS Design Guidelines draft.

> >As long as the compound format made sense for the actual entity
> >generating or processing the attribute's contents and as long as the
> >individual member values were not needed in any RADIUS policy nor
> >generated dynamically by the RADIUS server proper, there's never been
a
> >strong problem with such compound attributes, and I don't think there
> >necessarily should be any such problem now.
>=20
> I think this is a very reasonable distinction.  If there is no need to
> distinguish the member values, compound attributes are ok.  However,
if
> there is such a need, compounding is problematic, requiring code to be
> written that would not otherwise be necessary.  Reducing the need for
> continual code updates was the original purpose of the Dictionary,
after
> all.

The classic case of a compound attribute where RADIUS does not need to
parse (separate or distinguish) or take action upon (create or react to)
the member values is EAP-Message.  This attribute is an opaque blob to
RADIUS, so the case is simple, and degenerate.  No arguments there.

The distinction that is being proposed here is when a RADIUS RFC (one
defining RADIUS protocol elements, such as attributes) specifies a
compound attribute (e.g. one containing a structure) for which the
RADIUS protocol engine does not "care" about the individual member
elements, the attribute may be formatted as conveniently packed
bit-fields and octet fields.  We presume some of these fields may be
further defined in the textual descriptions as integers, bit-vectors,
Booleans, strings, arrays, etc.

I find it hard to quantify the "care" vs. "don't care" status of the
data elements.  It would seem to me that if the RADIUS protocol engine
doesn't "care" about the member elements, it does not need to know their
boundaries.  Hence we are back to the opaque blob.  If it *does* need to
know the boundaries, then I claim that it "cares" about the data
elements.

Now, I suppose we could attempt to define "levels of caring".  For
example, in the RADIUS/GEOPRIV draft, there are attributes that contain
a number of data elements, that when reassembled form a GEOPRIV data
structure.  Is it necessary for the RADIUS protocol engine to know their
boundaries? Well, one reason for knowing the boundaries is that the
RADIUS protocol engine might be expected to perform the data packing,
from a set of discrete data elements.  I would liken this to the "UPS
Store" analogy. The customer brings a collection of loose household
objects to the UPS Store to be packed and shipped.  The UPS Store
employees don't really "care" much about the objects.  They only care
about the properties that affect packing into cardboard cartons.  This
might include size, shape, weight, whether or not the object is fragile,
and whether or not the material is hazardous or otherwise subject to
special shipping regulations.

I personally object to the notion of RADIUS as a packager and shipper
for arbitrary applications, i.e. RADIUS as transport mechanism.  I
realize that it has been, and continues to be, used in this fashion,
usually for applications at least vaguely related to AAA.

I think another way to look at RADIUS attribute data element fields is
that if the RADIUS protocol engine needs to know they exist, then they
should fall under the attribute design guidelines.  Conversely if the
RADIUS protocol engine does not need to know that individual date
elements exist, then treat the complex data structure in the same
fashion that RADIUS treats EAP messages, as an opaque blob.

I think the argument that RADIUS cares "enough" about the individual
data elements to warrant defining them in explicit sub-fields of a
RADIUS attribute, but not so much as to require any regularization of
their on-the-wire encoding, is problematic.   The only scenario that I
see that justifies this middle-ground "level of caring" is the RADIUS as
transport case, i.e. the UPS Store model.

--
to unsubscribe send a message 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, 10 Mar 2006 15:10:10 +0000
Date: Fri, 10 Mar 2006 16:09:35 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Formats for structured attributes
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Thu, Mar 09, 2006 at 12:06:09PM -0500, Nelson, David wrote:

> Emile van Bergen writes...
>  
> > Where there are two bits of information for one attribute, pre-RADEXT
> > RADIUS has always taken the approach of simply putting them together
> > into C struct-like subfields. That can hardly come as a surprise, and
> > indeed, without a grouping mechanism, it's the most efficient and
> > sensible approach.
> > 
> > As long as the compound format made sense for the actual entity
> > generating or processing the attribute's contents and as long as the
> > individual member values were not needed in any RADIUS policy nor
> > generated dynamically by the RADIUS server proper, there's never been a
> > strong problem with such compound attributes, and I don't think there
> > necessarily should be any such problem now.
> 
> I think it would be very valuable to allow the expression of compound
> data elements in attribute formats that permit an extended form of data
> dictionary driven RADIUS server to add new instances of these attributes
> into the data dictionary.  What I advocate is a mechanism that
> regularizes the on-the-wire encoding of the equivalent of C-language
> structures in RADIUS attributes, such that new attributes can be added
> to a data dictionary, and the sub-elements of the structure can be
> described in that fashion.

An implementation of such a mechanism can be seen in OpenRADIUS; you can
there specify in the dictionary that an attribute contains a 'subspace',
and specify how that space is to be parsed: either as a list of fields
at fixed offsets or as a set of TLVs in whatever format. 

Each parsed item can then be addressed individually in administrator
defined policies.

> > Case in point: MS-CHAP2-Response (RFC 2548); this attribute only
> > makes sense as a whole and only to the actual MSCHAPv2 authenticator
> endpoint;
> > the values of the individual subfields are neither dynamically
> generated
> > at the RADIUS level nor interpreted by the server as part of
> > executing any local policy.
> 
> If you implement the MS-CHAP authenticator as a "plug-in" module to
> the RADIUS server, this makes some sense.

Whether or not you make that module an external plug in, it still holds
that the fewer cross dependencies, the better. 

If a dictionary driven RADIUS attribute layer is independent from the
policy engine and both are independent from the authenticators, then
everyting can evolve independently, without having to redesign everything
when one becomes obsolete. 

Currently, this is very well possible with RADIUS, even with most of the
baroque attributes that have sprung into existence over the years.

In the case of MS-CHAP, neither the packet decoder nor the policy engine
needs to know the internal structure of the CHAP Response attribute. And
the MS-CHAP authenticator only to know the value of that attribute,
together with a cleartext or RC4 password; it does not need any
knowledge about the packet or the server policy.

Another example is Ascend-Data-Filter; you can translate the textual
format into the binary format using an external tool, and simply put the
binary value in your user profile. The translation does not need to
happen separately for each request, and therefore no specific knowledge
about the attribute's internal syntax is needed by the packet encoder or
the policy engine.

A counterexample is Message-Authenticator: for verification, you need
to access both the RADIUS packet as a whole and the attribute itself,
and for generation it's worse: the attribute needs to be updated in situ
after the whole packet has been encoded. Thus, even the lowest layer of
a RADIUS implementation needed changes when this attribute was
introduced.

This was therefore a very problematic attribute, but of course it was
still the most reasonable solution for improving signatures for requests
and responses. The only alternative would be an extra fixed header,
which would create an incompatible protocol.

> > The current Extended Attribute draft uses the DIAMETER format, and the
> > only facility it has toward structured data is the 'Grouped' data
> > type, which is a *blank* container for *top level* attributes only.
> 
> Then maybe we need to discuss a more general notion of a regularized,
> and extensible data model for RADIUS that easily encompasses structured
> data.

My suggestion for the format of the attributes inside the Extended
Attribute space as described in
http://www.e-advies.nl/ietf/draft-evbergen-radext-extended-attribute-01.txt
proposes nested attributes to create structured data, and creates a
model with the following properties:

* All A/V pairs, including all subattrbutes, are still primarily made
  available as a flat list of TLVs, as in normal RADIUS, but with an
  additional Tag field as in RFC 2868. Relative ordering of instances of
  the same attribute is preserved.  

* Grouping pairs by their tags, you can create an ordered list of
  sets of A/V pairs, and uniquely address a set of pairs containing tag
  Y, or the n'th tagged set. This mechanism is already deployed in any
  NAS that supports RFC 2868.

  Thus, in a policy engine, pairs can be addressed uniquely as the
  n'th instance of attribute X with tag Y.

  Eg. (last)Tunnel-Media-Type:1 == IPv4

* Because any pair can refer to a tagged set of attributes as its 
  subordinates, using a dedicated Child-Tag field, you can create a
  nested structure of attributes.
  
  Any attribute of any type can at the same time convey a value as well
  as a set of subattributes. 

  Whether the attribute has a value, a set of subattributes, both, or
  none is *not* dependent on a-priori information about the attribute
  (eg. from the dictionary), but is made clear in the header: if the
  Length spans only the header, the attribute has no value, and if the
  Child-Tag field is zero, the attribute does not refer to any tagged
  set as its children.

* In addition to the Type field, each attribute contains a 32-bit
  STD/Vendor field that defines the number space for the Type field. It
  allows 2^24 vendors, 2^24 SDOs, 2^24 IETF standards to each govern
  2^32 attributes. 

  One particular value of the STD/Vendor field specifies that the
  attribute's Type number is to be interpreted relative to the parent
  attribute that refers to the tagged set as its child set. In other
  words, it allows each attribute to define subattributes without
  cluttering the global attribute number space.

  Because the 'locally numbered' subattributes exist in a distinct
  number space, no clashes occur, even if you look at all pairs as
  a flat list.

  While it is impossible to distinguish among *local* attributes of any
  type without looking at the nested structure created by the Tags and
  Child-Tags, it's still possible to distinguish all *local* attributes
  of a certain Type from all *global* attributes of that Type, because
  the former use a specific value in the STD/Vendor field.

* So, as long as you record each attribute's tag, child-tag, and
  preserve the relative ordering of all attributes of the same type,
  parsing a packet into a flat list does not cause you to loose any
  information at all.

  Thus, the packet decoder/encoder neither requires any knowledge about
  the nested data structure, nor does anything that addresses the
  structured data require knowledge that is only available in the
  encoder/decoder.

  The structure exists entirely on a level above the parsed list of
  Std/Vendor, Type, Tag, Child-Tag, Value tuples.

Thus, in addition to the tagged flat list perspective, my proposal for
structured data in RADIUS allows a policy engine to refer to
subattribute X in the unique tagged set that is referred to as a child
set by attribute Y.

An example: 

When a policy engine would parse a test for 
	
	Framed-Tunnel::Media-Type == IPv4, 
	
you'd first search for the STD/Vendor/Type tuple of a Framed-Tunnel
attribute in your dictionary. 

You would then look up the Type number for a Media-Type attribute that
is defined as a subattribute of Framed-Tunnel; if one is found, the
STD/Vendor/Type tuple is known, because all parent dependent attributes
use the same value for the STD/Vendor field.

If none is found, you would search for the Media-Type attribute in the
main dictionary to obtain the global STD/Vendor/Type tuple, if
Media-Type is a regular top level attribute.

Finally, you'd search for the constant value for 'IPv4' in the list of
named constants associated with that Media-Type (sub)attribute.

Then, you'd apply this test in your policy engine as follows:

Search for the first (or last) instance of the attribute on the request
list with the known 64-bit STD/Vendor/Type tuple belonging to
Framed-Tunnel, ignore the value, if any, and obtain the Child-Tag.

Next, search for the first (or last) instance of the attribute on the
request list with the known STD/Vendor/Type tuple belonging to
Media-Type and the tag found in the previous step.

You would then take the value of this instance of the attribute and 
compare it to the known value for IPv4 for this attribute. 

==

In short: in my proposal, all attributes can contain structured data,
member attributes don't need to be allocated a global Type number,
structuring can be done to any depth, and structure is preserved when
transporting a flat list of pairs.

Traversing the attribute space is simple and efficient; attributes are
aligned at 4-octet boundaries, just as with DIAMETER. By contrast,
searching for an instance of an attribute in a packet can be done using
a single unconditional 64-bit compare; each attribute starts with the
32-bit STD/Vendor field, followed by the 32-bit Type field.

The DIAMETER attribute Type space is fully incorporated, but
non-DIAMETER attributes can be defined as well, and room is created for
other SDOs to assign their own attribute Type spaces.

The only metadata about the value given by the attribute header is the
value's length in octets; without a priori knowledge of the attribute
(dictionary), the value's data type is unknown. Of course, that does not
prevent policy engines from comparing or retrieving such values; after
all, in addition to their native type, every value is also of the known
and well supported type 'string of octets'.

Of course, you may argue that this format is a bit too flexible and
provides too many ways to shoot yourself in the foot, but I think that
in cases like this, it's better to have strong style and strong data
type recommendations together with an expressive format, than a format
in which you cannot express bad thoughts at all. 

Structure evolves much slower than style, after all.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 10 Mar 2006 09:44:31 +0000
Date: Fri, 10 Mar 2006 10:44:06 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Thu, Mar 09, 2006 at 12:11:25PM -0500, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > Before disregarding C structures as proper solutions, I think that
> each
> > alternative solution should be carefully applied to the problem to see
> > how it plays out. This process is only just beginning in the WG, and
> > deprecating all existing practice *now* seems rather premature.
> 
> Are you suggesting that the RADEXT WG work items of RADIUS Attribute
> Design Guidelines and RADIUS Extended Attributes should be applied
> *only* to RADIUS related I-Ds that are submitted *after* RADEXT
> completes its work on all the other extensions on its charter?  IMHO, it
> would be cynical, to say the least, that we establish design guidelines
> and new attribute formats for others but exempt ourselves from paying
> heed to them.  Do as I say, not as I do.  :-(

Quite the contrary. *After* the Extended Attribute design is completed,
and tested against existing real world situations, and approved by rough
consensus, I would encourage that authors of *existing* I-Ds and even
standards documents revisit their material in the light of the new
recommendations.

However, as it is, the solution in the Delegated-IPv6-Prefix attribute
draft is more mature than the Extended Attribute design work. That's not
something to be overly worried about. A new attribute that follows a
template set out in an existing standard (RFC3162) will surely be done
in less time than a new, future proof design for structured data in
RADIUS.

Also, because it follows an existing standard (RFC3162), it can easily
be deployed *now* by any implementation that offers dictionary driven
support for the IPv6 attributes defined in RFC3162.

Finally, if you already have an Framed-IPv6-Prefix attribute that needs
review, adding a Delegated-IPv6-Prefix attribute with the exacy same
data type does not do any harm.

You're not suggesting that we have a Framed-IPv6-Prefix attribute with
one data type, and a Delegated-IPv6-Prefix that uses an entirely
different structure, do you?

Therefore, to make the Delegated-IPv6-Prefix wait for the new Extended
Attribute design would be entirely unreasonable. Indeed, to do so would
only make sense if you *do* hold the cynical view that only documents
submitted *after* the Extended Attribute and Design Guidelines work is
completed, need to pay any consideration to it.

I think it's more reasonable to expect that shortly after the Extended
Attribute work completes, people will provide review documents showing
in painstaking detail how existing solutions that leave something to be
desired, can be reimplemented using the new framework.

Those suggestions can then be adopted by the authors that want to update
their work.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message 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, 10 Mar 2006 07:34:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 09 Mar 2006 23:34:20 -0800

>As long as the compound format made sense for the actual entity
>generating or processing the attribute's contents and as long as the
>individual member values were not needed in any RADIUS policy nor
>generated dynamically by the RADIUS server proper, there's never been a
>strong problem with such compound attributes, and I don't think there
>necessarily should be any such problem now.

I think this is a very reasonable distinction.  If there is no need to 
distinguish the member values, compound attributes are ok.  However, if 
there is such a need, compounding is problematic, requiring code to be 
written that would not otherwise be necessary.  Reducing the need for 
continual code updates was the original purpose of the Dictionary, after 
all.

--
to unsubscribe send a message 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, 10 Mar 2006 04:23:34 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 20:23:04 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

> Avi Lior writes...
>=20
>> You as chair(s), slowed down other documents that were ready for last
>> call a long time ago to wait for completion of the Guideline
>> document.=20
>=20
> Readiness for last call is a subjective assessment.  Your opinion of
> the readiness of a given draft may differ from mine (and from
> others). =20
>=20
>> So why does one document get to go over another document?
>=20
> It's a case-by-case readiness assessment.  Not a FIFO.

That should go w/o saying.  However, the fact that it needs to be said =
begs the question of whom is doing the assessing.  I would think that =
the authors/editors of a document would be most capable of that =
judgment, in conjunction with the rough consensus of the rest of the WG =
(the chairs determining such via the mailing list).  This is clearly not =
the way this WG works, though (just one example: the 802 draft which =
emerged horribly broken from the design team & was funneled directly =
into last call).  I'm not picking on you & Bernard: this seems to be a =
kind of fad in the IETF, along with the establishment of design teams =
w/o any WG input & for no apparent technical reason.  Of course, this =
begs another, more interesting question, that of who's working for who.  =
I consider the position of WG chair to be a service position, with the =
major responsibility that (fraught with danger!) of gauging WG =
consensus.  Apparently I'm out-of-date: I guess we all work for you now.

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

Envelope-to: [email-masked]
Delivery-date: Fri, 10 Mar 2006 00:20:29 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: RADIUS Design Guidelines 
cc: [email-masked]
Date: Thu, 09 Mar 2006 19:27:58 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> "I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward.  The
> practice should be discouraged, but not forbidden."
> 
> Question:  what would you define as "existing formats"? 

  For the most part, attribute contents currently defined in the
RFC's.

> For example, the following compound attributes are described in
> RFC 2865, 2868, 2869 and 3162.   Note the similarity between
> RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix. 

  Yup.  There is existing code to deal with those attributes, so
adding more attributes of the same "format" isn't a major change to
RADIUS.

  Where those attributes require per-attribute special handling
(e.g. CHAP-Password), we should discourage new attributes of the same
format.  But even for those cases, I think most of the existing "odd"
formats are so special purpose that no one will be defining new
standards based on them.

 To iterate over the attributes you quoted:

> Section 5.3  CHAP-Password

  I think the WG will reject any attempt to define new authentication
methods based on CHAP.

> Attributes utilizing a one-octet tag field:

  Defining more tagged integers or strings will involve nothing more
than dictionary updates for most implementations.

> Section 5.5 ARAP-Features

  I don't even know if anyone is using this.  I do know many RADIUS
servers don't even support it, and the format is mostly an array of
values, which we could support through a slightly more complex data
model.

> 2.3 Framed-IPv6-Prefix

  Many implementations have IPv6 prefixes as a data type, so adding
more isn't much of a problem.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 10 Mar 2006 00:13:18 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Formats for structured attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") 
cc: [email-masked]
Date: Thu, 09 Mar 2006 19:20:40 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I think it would be very valuable to allow the expression of compound
> data elements in attribute formats that permit an extended form of data
> dictionary driven RADIUS server to add new instances of these attributes
> into the data dictionary.  What I advocate is a mechanism that
> regularizes the on-the-wire encoding of the equivalent of C-language
> structures in RADIUS attributes, such that new attributes can be added
> to a data dictionary, and the sub-elements of the structure can be
> described in that fashion.

  I think many protocol designers would like something similar.  This
is an issue across multiple WG's other than RADIUS.

  My previous company had some proposals in this space, but they never
went anywhere.

> Then maybe we need to discuss a more general notion of a regularized,
> and extensible data model for RADIUS that easily encompasses structured
> data.

  That would be extremely valuable.  The only caveat is that the data
model can't just model the layout of the data, it has to examine the
contents of the data in order to determine packing.

  e.g. Framed-IPv6-Prefix where trailing zeros don't have to be packed
into the attribute.

  The Samba people have an "IDL to C" compiler written in Perl.  It's
not perfect, but it's not that complicated.  Something similar could
be used here.

  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, 09 Mar 2006 23:30:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Re: RADIUS Design Guidelines
Date: Thu, 9 Mar 2006 15:30:29 -0800

Alan DeKok said:

"I have no objections to the guidelines permitting the definition of
new attributes that re-use existing formats, however awkward.  The
practice should be discouraged, but not forbidden."

Question:  what would you define as "existing formats"? 

For example, the following compound attributes are described in
RFC 2865, 2868, 2869 and 3162.   Note the similarity between
RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix. 

===========================================================================
RFC 2865

Section 5.3  CHAP-Password

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

   Request   Accept   Reject   Challenge   #    Attribute
   0-1       0        0        0            3   CHAP-Password [Note 1]

RFC 2868

Attributes utilizing a one-octet tag field: 

Tunnel-Type: tag + 3 octet value (Integer)
Tunnel-Medium-Type: tag + 3 octet value (Integer)
Tunnel-Client-Endpoint:  tag + string (String)
Tunnel-Server-Endpoint:  tag + string (String)
Tunnel-Password: tag + 2 octet salt + string (String)
Tunnel-Private-Group-ID: tag + string (String)
Tunnel-Assignment-ID: tag + string (String)
Tunnel-Preference: tag + 3 octet value (Integer)
Tunnel-Client-Auth-ID: tag + string (String)
Tunnel-Server-Auth-ID: tag + string (String)

Request Accept Reject Challenge Acct-Request #  Attribute
0+      0+     0      0         0-1          64 Tunnel-Type
0+      0+     0      0         0-1          65 Tunnel-Medium-Type
0+      0+     0      0         0-1          66 Tunnel-Client-Endpoint
0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
0       0+     0      0         0            69 Tunnel-Password
0+      0+     0      0         0-1          81 Tunnel-Private-Group-ID
0       0+     0      0         0-1          82 Tunnel-Assignment-ID
0+      0+     0      0         0            83 Tunnel-Preference
0+      0+     0      0         0-1          90 Tunnel-Client-Auth-ID
0+      0+     0      0         0-1          91 Tunnel-Server-Auth-ID

RFC 2869

Section 5.5 ARAP-Features

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

Request  Accept  Reject  Challenge   #    Attribute
0        0-1     0       0-1         71   ARAP-Features

RFC 3162

2.3 Framed-IPv6-Prefix

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

   Request Accept Reject Challenge Accounting  #  Attribute
                                   Request
   0+      0+     0      0         0+         97  Framed-IPv6-Prefix

--
to unsubscribe send a message 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, 09 Mar 2006 21:41:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Does RADIUS need a data model?
Date: Thu, 9 Mar 2006 16:41:07 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dan Romascanu writes...

> Was this issue discussed previously in the wg?=20

It was discussed extensively on the list during the BOF timeframe.  As a
result of those discussions, the design guidelines work item was added
to the charter.  It's fair to say, however, that no clear consensus
emerged from those discussions as to the exact nature of guidelines that
the WG would eventually adopt.

> Should you shortly raise it in Dallas, in connection with the Design=20
> Guidelines document (or not)?

I think this discussion will be a significant part of the WG dialog on
the design guidelines work items.  So, yes, we probably should.

--
to unsubscribe send a message 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, 09 Mar 2006 21:35:34 +0000
content-class: urn:content-classes:message
Subject: RE: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
Date: Thu, 9 Mar 2006 23:35:11 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Was this issue discussed previously in the wg? Should you shortly raise
it in Dallas, in connection with the Design Guidelines document (or
not)?

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, March 09, 2006 10:28 PM
> To: [email-masked]
> Subject: Does RADIUS need a data model? (was RE: RADEXT WG=20
> Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
>=20
> Glen Zorn writes...
>=20
> > Syntactically, I think that they are both strings.  Semantics are a=20
> > different ballgame, of course, but 2865 isn't really consistent on
> this
> > either.  In fact, RADIUS is (laudably or lamentably,=20
> depending on your
> > POV) pretty loose WRT to data typing.
>=20
> I think that Glen has summarized this nicely.  The loose data=20
> typing in RADIUS is definitely a double-edged sword.
>=20
> I believe that one reason that RADIUS (RFC 2865, RFC 2866)=20
> has been successful with its loose data typing is that it was=20
> largely written by a single author (the engineering staff at=20
> Livingston Enterprises).  When one has a uniformity of vision=20
> in the authoring process, formal rules for data typing are=20
> much less important.
>=20
> I also believe that subsequent RADIUS RFCs, issued after the=20
> closing of the RADIUS WG, have been, in varying degrees,=20
> substantially less successful in maintaining the unstated=20
> data model of RADIUS.  I attribute this to the fact that=20
> different authors were involved, with differing design=20
> perspectives, and no guideline to work with.
>=20
> I would like to see guidelines that would produce a more=20
> rational and self-consistent data model.  I don't think we=20
> need the formalism of something like SMI, as used in SNMP.  I=20
> do think some form of unified data typing, as part of a=20
> semi-formal data model, is desirable.
>=20
> I believe that the RADIUS Design Guidelines document should=20
> provide that kind of guidance.  I don't believe it goes far=20
> enough, in its current version, to address the issue of=20
> compound data types (structures).=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 09 Mar 2006 20:28:31 +0000
Content-class: urn:content-classes:message
Subject: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on  "RADIUS Delegated IPv6 Prefix Attribute")
Date: Thu, 9 Mar 2006 15:28:12 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> Syntactically, I think that they are both strings.  Semantics are a
> different ballgame, of course, but 2865 isn't really consistent on
this
> either.  In fact, RADIUS is (laudably or lamentably, depending on your
> POV) pretty loose WRT to data typing.

I think that Glen has summarized this nicely.  The loose data typing in
RADIUS is definitely a double-edged sword.

I believe that one reason that RADIUS (RFC 2865, RFC 2866) has been
successful with its loose data typing is that it was largely written by
a single author (the engineering staff at Livingston Enterprises).  When
one has a uniformity of vision in the authoring process, formal rules
for data typing are much less important.

I also believe that subsequent RADIUS RFCs, issued after the closing of
the RADIUS WG, have been, in varying degrees, substantially less
successful in maintaining the unstated data model of RADIUS.  I
attribute this to the fact that different authors were involved, with
differing design perspectives, and no guideline to work with.

I would like to see guidelines that would produce a more rational and
self-consistent data model.  I don't think we need the formalism of
something like SMI, as used in SNMP.  I do think some form of unified
data typing, as part of a semi-formal data model, is desirable.

I believe that the RADIUS Design Guidelines document should provide that
kind of guidance.  I don't believe it goes far enough, in its current
version, to address the issue of compound data types (structures).=20

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

Delivery-date: Thu, 09 Mar 2006 19:57:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 14:57:45 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> You as chair(s), slowed down other documents that were ready=20
> for last call a long time ago to wait for completion of the=20
> Guideline document.

Readiness for last call is a subjective assessment.  Your opinion of the
readiness of a given draft may differ from mine (and from others).

> So why does one document get to go over another document?=20

It's a case-by-case readiness assessment.  Not a FIFO.

--
to unsubscribe send a message 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, 09 Mar 2006 19:26:27 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 14:28:57 -0500
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

David,

You as chair(s), slowed down other documents that were ready for last
call a long time ago to wait for completion of the Guideline document. =20

So why does one document get to go over another document?  Lets be
evenhanded!!!

Avi

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, March 09, 2006 2:16 PM
> To: [email-masked]
> Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6=20
> Prefix Attribute"
>=20
> John Schnizlein writes...
>=20
> > That does not seem to me to be the (cynical) suggestion. =20
> Rather the=20
> > suggestion is that it is premature to hold up a last-call WG draft=20
> > because it does not comply with an individual draft, not ready for
> last
> > call.
>=20
> I think for this particular draft, we have all agreed that=20
> the proposed format is acceptable.  Some of the comments in=20
> this thread, however, are phrased in such a way as to apply=20
> to other documents, not yet in last call.  My comments were=20
> intended to draw a distinction between the case for *this*=20
> document and various others.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 09 Mar 2006 19:15:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 14:15:45 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

John Schnizlein writes...

> That does not seem to me to be the (cynical) suggestion.  Rather the
> suggestion is that it is premature to hold up a last-call WG draft
> because it does not comply with an individual draft, not ready for
last
> call.

I think for this particular draft, we have all agreed that the proposed
format is acceptable.  Some of the comments in this thread, however, are
phrased in such a way as to apply to other documents, not yet in last
call.  My comments were intended to draw a distinction between the case
for *this* document and various others.

--
to unsubscribe send a message 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, 09 Mar 2006 19:11:08 +0000
Cc: "<[email-masked]>" <[email-masked]>, Ralph Droms ((rdroms)) <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 14:10:45 -0500
To: "Nelson, David" <[email-masked]>

On Mar 9, 2006, at 12:11 PM, Nelson, David wrote:

> Emile van Bergen writes...
>
>> Before disregarding C structures as proper solutions, I think that 
>> each
>> alternative solution should be carefully applied to the problem to see
>> how it plays out. This process is only just beginning in the WG, and
>> deprecating all existing practice *now* seems rather premature.
>
> Are you suggesting that the RADEXT WG work items of RADIUS Attribute
> Design Guidelines and RADIUS Extended Attributes should be applied
> *only* to RADIUS related I-Ds that are submitted *after* RADEXT
> completes its work on all the other extensions on its charter?  IMHO, 
> it
> would be cynical, to say the least, that we establish design guidelines
> and new attribute formats for others but exempt ourselves from paying
> heed to them.  Do as I say, not as I do.  :-(

That does not seem to me to be the (cynical) suggestion.  Rather the 
suggestion is that it is premature to hold up a last-call WG draft 
because it does not comply with an individual draft, not ready for last 
call.

February 25, 2006      draft-ietf-radext-delegated-prefix-00.txt - now 
in last call
March 5, 2006          draft-weber-radius-attr-guidelines-02.txt - on 
the IETF 65 agenda for discussion

It has already been noted that the format proposed is consistant  with 
RFC 3162.

John

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

Delivery-date: Thu, 09 Mar 2006 17:11:32 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 12:11:25 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> Before disregarding C structures as proper solutions, I think that
each
> alternative solution should be carefully applied to the problem to see
> how it plays out. This process is only just beginning in the WG, and
> deprecating all existing practice *now* seems rather premature.

Are you suggesting that the RADEXT WG work items of RADIUS Attribute
Design Guidelines and RADIUS Extended Attributes should be applied
*only* to RADIUS related I-Ds that are submitted *after* RADEXT
completes its work on all the other extensions on its charter?  IMHO, it
would be cynical, to say the least, that we establish design guidelines
and new attribute formats for others but exempt ourselves from paying
heed to them.  Do as I say, not as I do.  :-(

--
to unsubscribe send a message 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, 09 Mar 2006 17:06:14 +0000
Content-class: urn:content-classes:message
Subject: Formats for structured attributes (was RE: RADEXT WG Last Call on  "RADIUS Delegated IPv6 Prefix Attribute")
Date: Thu, 9 Mar 2006 12:06:09 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...
=20
> Where there are two bits of information for one attribute, pre-RADEXT
> RADIUS has always taken the approach of simply putting them together
> into C struct-like subfields. That can hardly come as a surprise, and
> indeed, without a grouping mechanism, it's the most efficient and
> sensible approach.
>=20
> As long as the compound format made sense for the actual entity
> generating or processing the attribute's contents and as long as the
> individual member values were not needed in any RADIUS policy nor
> generated dynamically by the RADIUS server proper, there's never been
a
> strong problem with such compound attributes, and I don't think there
> necessarily should be any such problem now.

I think it would be very valuable to allow the expression of compound
data elements in attribute formats that permit an extended form of data
dictionary driven RADIUS server to add new instances of these attributes
into the data dictionary.  What I advocate is a mechanism that
regularizes the on-the-wire encoding of the equivalent of C-language
structures in RADIUS attributes, such that new attributes can be added
to a data dictionary, and the sub-elements of the structure can be
described in that fashion.

> Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes
> sense as a whole and only to the actual MSCHAPv2 authenticator
endpoint;
> the values of the individual subfields are neither dynamically
generated
> at the RADIUS level nor interpreted by the server as part of executing
> any local policy.

If you implement the MS-CHAP authenticator as a "plug-in" module to the
RADIUS server, this makes some sense.
=20
> If we want to deprecate ALL forms of C-structure like attributes, and
> expose all subfields as individual attributes, however grouped, then
for
> sure any new proposal for structuring needs a *thorough* assessment
> whether it can meet the challenge.

I don't want to deprecate them, per se.  I want to regularize them for
new work, as described above.  As to the need to thorough review of any
such proposal, and the desired timing of such work, I reiterate that I
think that is the single most important work item for RADEXT.  That's
why it was originally listed as one of the first milestones that WG was
supposed to deliver.  IMHO, it is lamentable that we are only now giving
this serious attention, but better late than never.

> The current Extended Attribute draft uses the DIAMETER format, and the
> only facility it has toward structured data is the 'Grouped' data
type,
> which is a *blank* container for *top level* attributes only.

Then maybe we need to discuss a more general notion of a regularized,
and extensible data model for RADIUS that easily encompasses structured
data.

--
to unsubscribe send a message 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, 09 Mar 2006 17:04:02 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 09:03:34 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Emile van Bergen <> supposedly scribbled:
...

> Before disregarding C structures as proper solutions, I think that
> each alternative solution should be carefully applied to the problem
> to see how it plays out. This process is only just beginning in the
> WG, and deprecating all existing practice *now* seems rather
> premature. =20

Well put.
 =20
~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 09 Mar 2006 14:15:42 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 9 Mar 2006 09:17:57 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Hi Alan,=20

See inline.....

>   I have no objections to the guidelines permitting the=20
> definition of new attributes that re-use existing formats,=20
> however awkward.  The practice should be discouraged, but not=20
> forbidden.

Okay.
=20
>   Therefore, I have no objections to this format, or this document.
>=20
>   Alan DeKok.
>=20

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

Delivery-date: Thu, 09 Mar 2006 10:43:31 +0000
Date: Thu, 9 Mar 2006 11:42:52 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Wed, Mar 08, 2006 at 06:03:11PM -0500, Nelson, David wrote:

> Alan DeKok writes...
>  
> >   Yes, though this document simply re-uses the existing standards
> > track type defined in 3162.
> 
> There are several examples of new data formats, generally speaking
> complex or compound data types, that appear in RADIUS RFCs, both
> Standards Track and Informational, that were published after the close
> of the RADIUS WG and before the chartering of the RADEXT WG.  I have no
> idea how much review and comment each of these documents received by the
> IESG and the IETF at large.  Certainly, there was no attribute design
> guideline at the time, and probably no designated expert to review
> proposed attributes.
> 
> It is important to document these practices in the RADIUS Attribute
> Design Guidelines draft.  We need to recognize their existence, and
> therefore their validity.  I also believe that we want to strongly
> discourage further use of "novel" attribute formats, in any new work.

Let's keep it into perspective. The attribute in this document and in
3162 needs to convey two pieces of information: a prefix length, and the
actual prefix.

Where there are two bits of information for one attribute, pre-RADEXT
RADIUS has always taken the approach of simply putting them together
into C struct-like subfields. That can hardly come as a surprise, and
indeed, without a grouping mechanism, it's the most efficient and
sensible approach.

As long as the compound format made sense for the actual entity
generating or processing the attribute's contents and as long as the
individual member values were not needed in any RADIUS policy nor
generated dynamically by the RADIUS server proper, there's never been a
strong problem with such compound attributes, and I don't think there
necessarily should be any such problem now.

Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes
sense as a whole and only to the actual MSCHAPv2 authenticator endpoint;
the values of the individual subfields are neither dynamically generated
at the RADIUS level nor interpreted by the server as part of executing
any local policy.

If we want to deprecate ALL forms of C-structure like attributes, and
expose all subfields as individual attributes, however grouped, then for
sure any new proposal for structuring needs a *thorough* assessment
whether it can meet the challenge.

The current Extended Attribute draft uses the DIAMETER format, and the
only facility it has toward structured data is the 'Grouped' data type,
which is a *blank* container for *top level* attributes only.

My alternative suggestion for the Extended Attribute contents at
<http://www.e-advies.nl/ietf/draft-evbergen-radext-extended-attribute-01.txt>
allows RFC2868-style tags for all attributes and allows any attribute to
refer to a tagged set to create lightly structured data.

Attributes that are only meaningful as members of a structured
attribute, can use parent attribute dependent Type numbers, so that they
need not be assigned a number from the global attribute type registry.

Before disregarding C structures as proper solutions, I think that each
alternative solution should be carefully applied to the problem to see
how it plays out. This process is only just beginning in the WG, and
deprecating all existing practice *now* seems rather premature.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Envelope-to: [email-masked]
Delivery-date: Wed, 08 Mar 2006 23:20:47 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" 
cc: [email-masked]
Date: Wed, 08 Mar 2006 18:27:59 -0500
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> Good argument, except that 3162 nowhere uses the word "type" except as
> the name of an attribute field.  Since RFC 3162 doesn't define any
> types, it seems hard to substantiate your claim of an existing type, let
> alone a standard one.

  <shrug>  Format, syntax, string, type, whatever you call it.  This
document adds nothing new over 3162, and 3162 is standards track.

  To a large extent, format and syntax define type.  Whether the
document says this or not is a different story.

  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, 08 Mar 2006 23:06:18 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" 
Date: Wed, 8 Mar 2006 15:06:12 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Avi Lior" <[email-masked]>
Cc: <[email-masked]>

Alan DeKok <> supposedly scribbled:

> "Avi Lior" <[email-masked]> wrote:
>> The closest RADIUs type would be string.  Neither 3162 nor this
>> document defines the type as string.  In essence both documents (and
>> thank god they are consistant) are defining a new type, which is a
>> compound type, that contains a length field counting bits, Octet
>> based variable length array containing bits.

Syntactically, I think that they are both strings.  Semantics are a =
different ballgame, of course, but 2865 isn't really consistent on this =
either.  In fact, RADIUS is (laudably or lamentably, depending on your =
POV) pretty loose WRT to data typing.

>=20
>   Yes, though this document simply re-uses the existing standards
> track type defined in 3162.=20

Good argument, except that 3162 nowhere uses the word "type" except as =
the name of an attribute field.  Since RFC 3162 doesn't define any =
types, it seems hard to substantiate your claim of an existing type, let =
alone a standard one.

>=20
>> I don't think EXTATTR folks are thinking about encoding attributes
>> the way this document and 3162 is proposing -- so that is out of the
>> question.=20

Maybe they should be?  Seems kind of useful...

>>=20
>> So perhaps the Guidelines document should be changed to allow for
>> this encoding.  That would be my choice.

That's OK, too.

>=20
>   I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward.  The
> practice should be discouraged, but not forbidden. =20
>=20
>   Therefore, I have no objections to this format, or this document.
>=20
>   Alan DeKok.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 08 Mar 2006 23:03:37 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" 
Date: Wed, 8 Mar 2006 18:03:11 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...
=20
>   Yes, though this document simply re-uses the existing standards
> track type defined in 3162.

There are several examples of new data formats, generally speaking
complex or compound data types, that appear in RADIUS RFCs, both
Standards Track and Informational, that were published after the close
of the RADIUS WG and before the chartering of the RADEXT WG.  I have no
idea how much review and comment each of these documents received by the
IESG and the IETF at large.  Certainly, there was no attribute design
guideline at the time, and probably no designated expert to review
proposed attributes.

It is important to document these practices in the RADIUS Attribute
Design Guidelines draft.  We need to recognize their existence, and
therefore their validity.  I also believe that we want to strongly
discourage further use of "novel" attribute formats, in any new work.

It is important that the RADIUS Attribute Design Guidelines draft,
coupled with the RADIUS Extended Attribute draft, cover all of the needs
for attribute data modeling.  If an important data type is missing, or
cannot be created as derived a data type in a straightforward fashion,
then that shortcoming needs to be addressed in the these two documents.

I would stop short of saying that any "novel" attribute formats that
have been published in any given RADIUS RFC since the closing of the
RADIUS WG should be considered suitable for new design.

>   I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward.  The
> practice should be discouraged, but not forbidden.

Well, as a BCP, the RADIUS Attribute Design Guidelines cannot actually
*forbid* anything, but I think the discouragement for creating (or
re-using) "novel" formats not included in RFC 2865, the RADIUS Attribute
Design Guidelines or the RADIUS Extended Attribute documents should be
very strong indeed.  The desire is to prevent a fragmentation of the
RADIUS attribute data model, such as it is, into some form of Tower of
Babel, at least going forward.=20

>   Therefore, I have no objections to this format, or this document.

Given that we are attempting to quickly address an issue with existing
usages (a la RFC 3162) it may be acceptable to re-use that attribute
format in this draft.  I would not support a general grandfathering of
all such attribute formats for new work, including many of the existing
RADEXT WG work items.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 08 Mar 2006 22:23:44 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" 
cc: [email-masked]
Date: Wed, 08 Mar 2006 17:31:03 -0500
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> The closest RADIUs type would be string.  Neither 3162 nor this document
> defines the type as string.  In essence both documents (and thank god
> they are consistant) are defining a new type, which is a compound type,
> that contains a length field counting bits, Octet based variable length
> array containing bits.

  Yes, though this document simply re-uses the existing standards
track type defined in 3162.

> I don't think EXTATTR folks are thinking about encoding attributes the
> way this document and 3162 is proposing -- so that is out of the
> question.
> 
> So perhaps the Guidelines document should be changed to allow for this
> encoding.  That would be my choice.

  I have no objections to the guidelines permitting the definition of
new attributes that re-use existing formats, however awkward.  The
practice should be discouraged, but not forbidden.

  Therefore, I have no objections to this format, or this 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: Wed, 08 Mar 2006 22:08:10 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Wed, 8 Mar 2006 17:10:32 -0500
From: "Avi Lior" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Glen,=20

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]=20
> Sent: Wednesday, March 08, 2006 3:36 PM
> To: Avi Lior
> Cc: Bernard Aboba; [email-masked]
> Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6=20
> Prefix Attribute"
>=20
> Avi Lior <> supposedly scribbled:
>=20
> > I hate to bring this up but the format of this attribute does not=20
> > adhere to 2865
>=20
> How so?
Where shall I begin?

The closest RADIUs type would be string.  Neither 3162 nor this document
defines the type as string.  In essence both documents (and thank god
they are consistant) are defining a new type, which is a compound type,
that contains a length field counting bits, Octet based variable length
array containing bits.

> > nor to the RADIUS Attribute Guidelines recommendation.=20
> So which one should change?

Ah another good question.  It depends who you ask.  But lets see what
are the options:

If you want to keep the encoding then:

I think if you read the guideline document, if this format should be
allowed to stand then it should be covered by RADIUS EXTATTR.  Since the
recommendation in the GUIDELINE document is that any new types should
conform to that document.

Next, the Guideline document could be changed to allow for this
encoding.

Finally, the document should be changed.

If you ask me:

The last option would be sad indeed given the consistancy of the
proposed encoding with 3162.

I don't think EXTATTR folks are thinking about encoding attributes the
way this document and 3162 is proposing -- so that is out of the
question.

So perhaps the Guidelines document should be changed to allow for this
encoding.  That would be my choice.

Maybe others can chirp in. If memory serves me right, based on previous
intense discussions, I am totally surprized by the silence of the chairs
on this matter.

>=20
> >=20
> > Avi
> >=20
> >=20
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> >> Sent: Friday, March 03, 2006 3:02 PM
> >> To: [email-masked]
> >> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20
> >> Attribute"
> >>=20
> >> This is an announcement of RADEXT WG last call on the "RADIUS
> >> Delegated-IPv6 Prefix Attribute"
> >> document, prior to sending this document on to the IESG for=20
> >> consideration as a Proposed Standard.
> >>=20
> >> The document is available for inspection here:
> >>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefi
> >> x-00.txt
> >>=20
> >> RADEXT WG last call will last until Monday March 27, 2006.
> >> Please send your comments to the RADEXT WG list
> >> ([email-masked]) in the format described on the=20
> RADEXT Issues=20
> >> List: http://www.drizzle.com/~aboba/RADEXT/
> >>=20
> >> Since all RADEXT WG last calls require at least 5=20
> reviewers in order=20
> >> to advance the document, please respond indicating that=20
> you have read=20
> >> the document and find it acceptable, even if you have no issues to=20
> >> file.
> >>=20
> >>=20
> >>=20
> >> --
> >> to unsubscribe send a message to=20
> [email-masked] with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://psg.com/lists/radiusext/>
>=20
> Hope this helps,
>=20
> ~gwz
>=20
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
>=20

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

Delivery-date: Wed, 08 Mar 2006 20:50:15 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-digest-auth-07.txt 
Date: Wed, 08 Mar 2006 15:50:02 -0500

--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 Extension for Digest Authentication
	Author(s)	: B. Sterman, et al.
	Filename	: draft-ietf-radext-digest-auth-07.txt
	Pages		: 39
	Date		: 2006-3-8
	
This document defines an extension to the Remote Authentication Dial
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-digest-auth-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-digest-auth-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-digest-auth-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-digest-auth-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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: Wed, 08 Mar 2006 20:36:24 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Wed, 8 Mar 2006 12:36:10 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Avi Lior <> supposedly scribbled:

> I hate to bring this up but the format of this attribute does not
> adhere to 2865=20

How so?

> nor to the RADIUS Attribute Guidelines recommendation.=20

So which one should change?

>=20
> Avi
>=20
>=20
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Bernard Aboba
>> Sent: Friday, March 03, 2006 3:02 PM
>> To: [email-masked]
>> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix
>> Attribute"=20
>>=20
>> This is an announcement of RADEXT WG last call on the "RADIUS
>> Delegated-IPv6 Prefix Attribute"
>> document, prior to sending this document on to the IESG for
>> consideration as a Proposed Standard.
>>=20
>> The document is available for inspection here:
>> =
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00=
.txt
>>=20
>> RADEXT WG last call will last until Monday March 27, 2006.
>> Please send your comments to the RADEXT WG list
>> ([email-masked]) in the format described on the RADEXT
>> Issues List: http://www.drizzle.com/~aboba/RADEXT/
>>=20
>> Since all RADEXT WG last calls require at least 5 reviewers in order
>> to advance the document, please respond indicating that you have read
>> the document and find it acceptable, even if you have no issues to
>> file.=20
>>=20
>>=20
>>=20
>> --
>> to unsubscribe send a message to [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 08 Mar 2006 20:11:45 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Wed, 8 Mar 2006 15:13:57 -0500
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I hate to bring this up but the format of this attribute does not adhere
to 2865 nor to the RADIUS Attribute Guidelines recommendation.=20

Avi
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, March 03, 2006 3:02 PM
> To: [email-masked]
> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20
> Attribute"
>=20
> This is an announcement of RADEXT WG last call on the "RADIUS=20
> Delegated-IPv6 Prefix Attribute"
> document, prior to sending this document on to the IESG for=20
> consideration as a Proposed Standard.
>=20
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-delegate
d-prefix-00.txt
>=20
> RADEXT WG last call will last until Monday March 27, 2006. =20
> Please send your comments to the RADEXT WG list=20
> ([email-masked]) in the format described on the=20
> RADEXT Issues List:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> Since all RADEXT WG last calls require at least 5 reviewers=20
> in order to advance the document, please respond indicating=20
> that you have read the document and find it acceptable, even=20
> if you have no issues to file.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 08 Mar 2006 13:58:03 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: things fixed in RADIUS Digest -07 
Date: Wed, 8 Mar 2006 14:56:33 +0100 

IESG Comments
-------------

[hartmans]
Rejection of Client Nonces
- see 3.3
"If the server cannot choose a nonce, it replies with an
Access-Reject".

[hartmans, townsley (Zorn)]
Client Nonce Replay Attack
- defined a client nonce format with an embedded sequence number

[rhousley]
Missing CHAP reference:
- fixed

MUST for operator advice
section 2.
"the operator MUST make sure [..] "
changed to "the operator must make sure [..]"

[bwijnen]
IP addresses in examples
- changed to 192.0.2.0/24 range

[jpeterson]
WWW-Authenticate / Response code mismatch in example
- fixed

Motivation Section
- fixed wrong notion that RfC 3261 tries to supplant Digest-Auth

[sah]
IANA
- removed preferred values

Issues from the Issue tracker
-----------------------------

Issue 151:
Abstract
- spelled out abbreviations

Terminology
- spelled out abbreviations
- more detailed explanation of protection space

Client Behavior
- fixed typos
- used Kurt's proposed sentence concerning Digest-Nextnonce handling
- did not change 'without quotes', as the RADIUS client can be
transparent

Issue 152:
- split up the text in sub sections to enhance
readability

Issue 159:
- added a section about configuration parameters on the RADIUS client

Issue: 173-175:
see IESG comments

Wolfgang
--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message 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, 08 Mar 2006 02:13:39 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-weber-radius-attr-guidelines-02.txt 
Date: Tue, 7 Mar 2006 21:13:15 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64255.DC9830CB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
FYI, this is an IETF-65 RADEXT agenda item.
Comments to the list, please.

Greg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: Tuesday, March 07, 2006 8:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-weber-radius-attr-guidelines-02.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
>=20
> 	Title		: Design Guidelines for RADIUS Attributes
> 	Author(s)	: G. Weber
> 	Filename	: draft-weber-radius-attr-guidelines-02.txt
> 	Pages		: 15
> 	Date		: 2006-3-7
> =09
> This memo explores various issues related to the data model used by
>    the Remote Authentication Dial In User Service (RADIUS) protocol.
>    Recommendations are made to facilitate internal alignment and
>    uniformity.  Attribute design guidelines are also provided.
>=20
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
2.txt
>=20

------_=_NextPart_001_01C64255.DC9830CB
Content-Type: application/octet-stream;
	name="draft-weber-radius-attr-guidelines-02.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-weber-radius-attr-guidelines-02.URL
Content-Disposition: attachment;
	filename="draft-weber-radius-attr-guidelines-02.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC13ZWJlci1yYWRpdXMtYXR0ci1ndWlkZWxpbmVzLTAyLnR4dA0K

------_=_NextPart_001_01C64255.DC9830CB--

--
to unsubscribe send a message 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, 07 Mar 2006 22:01:07 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: AD review: radius dynauth client/server mib documents
Date: Tue, 7 Mar 2006 23:00:33 +0100 

W.r.t.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, March 07, 2006 21:13
> To: Wijnen, Bert (Bert)
> Cc: Nelson, David; [email-masked]
> Subject: Re: AD review: radius dynauth client/server mib documents
> 
> 
> 
> Hi,
> 
> see below...
> 
> Wijnen, Bert (Bert) wrote:
> 
> > Inline
> > 
> > 
> >>-----Original Message-----
> >>From: Nelson, David [mailto:[email-masked]]
> >>Sent: Friday, March 03, 2006 16:40
> >>To: Wijnen, Bert (Bert); [email-masked]
> >>Subject: RE: AD review: radius dynauth client/server mib documents
> >>
> >>
> >>Bert Wijnen writes...
> >>
> >>
> >>>2. The a whole serioes of Counter32 objects.
> >>>   I wonder what the object is to indicate a counter-discontinuity?
> >>>   Or can such only happen at system restart/reboot?
> >>>   See RFC2578 that explains this in sect 7.1.6
> >>>   RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.
> >>
> >>RFC2578 Section 7.1.6:
> >>
> >>   The Counter32 type represents a non-negative integer which
> >>   monotonically increases until it reaches a maximum value 
> of 2^32-1
> >>   (4294967295 decimal), when it wraps around and starts increasing
> >>   again from zero.
> >>
> >>   Counters have no defined "initial" value, and thus, a 
> >>single value of
> >>   a Counter has (in general) no information content.  
> Discontinuities
> >>   in the monotonically increasing value normally occur at re-
> >>   initialization of the management system, and at other times as
> >>   specified in the description of an object-type using this 
> >>ASN.1 type.
> >>   If such other times can occur, for example, the creation 
> >>of an object
> >>   instance at times other than re-initialization, then a 
> >>corresponding
> >>   object should be defined, with an appropriate SYNTAX clause, to
> >>   indicate the last discontinuity.  Examples of appropriate SYNTAX
> >>   clause include:  TimeStamp (a textual convention defined in [3]),
> >>   DateAndTime (another textual convention from [3]) or TimeTicks.
> >>
> >>RFC4181 Section 4.6.1.2 (1st bullet):
> >>
> >>   - It is OK to use Counter32/64 for counters that 
> may/will be reset
> >>     when the management subsystem is re-initialized or when other
> >>     unusual/irregular events occur (e.g., counters 
> >>maintained on a line
> >>     card may be reset when the line card is reset).  
> >>However, if it is
> >>     possible for such other unusual/irregular events to occur, the
> >>     DESCRIPTION clause MUST state that this is so and MUST describe
> >>     those other unusual/irregular events in sufficient 
> detail that it
> >>     is possible for a management application to determine whether a
> >>     reset has occurred since the last time the counter was 
> >>polled.  The
> >>     RECOMMENDED way to do this is to provide a discontinuity 
> >>indicator
> >>     as described in RFC 2578 Sections 7.1.6 and 7.1.10.  For 
> >>an example
> >>     of such a discontinuity indicator, see the
> >>     ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
> >>
> >>So I take it that the normal wrapping from maximum value to 
> >>zero is OK,
> >>and reset upon system (re)initialization is OK, but any other
> >>"discontinuity" needs special attention.  Is that right? 
> >>
> > 
> > Yes, and that is why I had a very simple solution proposed later in
> > my review message. By adding that sentence, we make it clear that
> > we have thought about this and that such is indeed the case 
> (assuming 
> > that I got it right). By not saying anything about it, it could
> > be an unintended omission.
> > 
> 
> Ok, I will add a sentence the overview section to mention this. I 
> believe this is better than in the MIB itself to avoid repeating the 
> same for each object again.
> 
Well, I strongly recommend to put it in the MIB module itself.
Normally I ask it to be in the DESCRIPTION clause of every object.
SO if you do a revision anyway, then I prefer that.
If you find that too much work, I would settle for it to occur
once in the xxxTable or xxxEntry DESCRIPTION clause to explain that
all COunter32 objets in this table have that behaviour w.r.t.
discontinuities.

> Also the reference to the IANA copy-right web page will be removed.
> 
Good

Bert
> thanks,
> Stefaan
> 
> 
> 
> > 
> >>>  So, the radiusDynAuthClientAddress needs to specify that 
> >>
> >>the address
> >>is
> >>
> >>>  formatted according to the value of 
> >>
> >>radiusDynAuthClientAddressType.
> >>
> >>>  Also, as far as I can tell, any addressType could be 
> present here,
> >>>  so formally, you would need to describe when a dns name has been
> >>>  resolved (if it occurs).
> >>
> >>RADIUS normally deals with IP Addresses, as the RADIUS 
> client needs to
> >>be registered with the RADIUS Server by IP Address, so that 
> >>the correct
> >>shared secret can be used.  It is possible to use DNS with RADIUS
> >>clients and servers, if sufficient care is taken to always have an
> >>accurate inverse name resolution available, but I believe 
> this is not
> >>common practice.
> >>
> > 
> > 
> > I think that answer is suffient for me.
> > 
> > Bert
> > 
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 07 Mar 2006 22:00:59 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Cc: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: radius dynauth client/server mibs structure
Date: Tue, 7 Mar 2006 23:00:32 +0100 

I am happy to chekc a pre-release rev 04 as well.

Bert

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Tuesday, March 07, 2006 21:24
> To: [email-masked]
> Cc: Nagi Reddy Jonnala (njonnala); [email-masked];
> [email-masked]; Wijnen, Bert (Bert)
> Subject: RE: radius dynauth client/server mibs structure
> 
> 
> Stefaan DeCnodder writes...
>  
> > Since the suggestion has sufficient support it is best to 
> do so. Is it
> > Ok to sent a version -04 of both docs after the IETF containing all
> > updates?
> 
> That would be best.  You can submit -04 any time that it is ready (all
> the changes are incorporated).  It won't be published until after
> IETF-65.  I-D submissions are now queued for publication, as 
> opposed to
> bounced, during the IETF meeting "blackout" periods.
> 
> While you are at it, though, all the other nits in the -03 drafts that
> could have been addressed with RFC Editor notes should be 
> incorporated,
> to keep the process as simple as possible.
> 
> It would also be appropriate to send the "diff" text to the RADEXT WG
> list before submitting tie -04 drafts, so that the WG gets to look at
> the proposed issue resolutions in detail.  We have discussed 
> them on the
> list, so I think folks are generally aware, but posting the exact text
> would be helpful.
> 
> -- Dave
> 

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

Delivery-date: Tue, 07 Mar 2006 20:24:14 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Tue, 7 Mar 2006 15:23:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>

Stefaan DeCnodder writes...
=20
> Since the suggestion has sufficient support it is best to do so. Is it
> Ok to sent a version -04 of both docs after the IETF containing all
> updates?

That would be best.  You can submit -04 any time that it is ready (all
the changes are incorporated).  It won't be published until after
IETF-65.  I-D submissions are now queued for publication, as opposed to
bounced, during the IETF meeting "blackout" periods.

While you are at it, though, all the other nits in the -03 drafts that
could have been addressed with RFC Editor notes should be incorporated,
to keep the process as simple as possible.

It would also be appropriate to send the "diff" text to the RADEXT WG
list before submitting tie -04 drafts, so that the WG gets to look at
the proposed issue resolutions in detail.  We have discussed them on the
list, so I think folks are generally aware, but posting the exact text
would be helpful.

-- Dave

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

Delivery-date: Tue, 07 Mar 2006 20:16:19 +0000
Date: Tue, 07 Mar 2006 21:15:57 +0100
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: radius dynauth client/server mibs structure

Hi,

Since the suggestion has sufficient support it is best to do so. Is it 
Ok to sent a version -04 of both docs after the IETF containing all updates?

regards,
Stefaan

Wijnen, Bert (Bert) wrote:

> Inline
> 
> 
>>-----Original Message-----
>>From: Nelson, David [mailto:[email-masked]]
>>Sent: Friday, March 03, 2006 16:45
>>To: Wijnen, Bert (Bert); Nagi Reddy Jonnala (njonnala);
>>[email-masked]; [email-masked]
>>Subject: RE: radius dynauth client/server mibs structure
>>
>>
>>Bert Wijnen writes...
>>
>>
>>>The disadvantage of not doing so is in the future when 
>>
>>adding scalars
>>
>>>and thing not having grouped as nicely and so more complexity.
>>
>>In practice, does this inconvenient grouping really affect any SNMP
>>applications in a user-visible way, except for MIB-walk and 
>>MIB-browser applications?
>>
> 
> 
> I know from experience that it made it easier for me to implement the
> MIB at the agent side. Of course that could have been caused just by my
> owb design, and other may not have trouble with it at all.
> 
> I am somewhat less familiar with mgmt apps.
> 
> 
>>>This is not a blocking comment, just another MIB-type person believing
>>>that the change would be real EASY now, and it will certainly make
>>>things cleaner/easier in the future.
>>
>>It certainly makes the MIB _document_ neater.
>>
> 
> 
> And rigth now (at FIRST or INITIAL version) it is EASY to make the change
> to make something neat. Later you cannot correct it without possibly
> deprecating/obsoleteing existing and adding new objects.
> 
> Oh well.
> 
> Bert
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 07 Mar 2006 20:13:21 +0000
Date: Tue, 07 Mar 2006 21:12:49 +0100
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: AD review: radius dynauth client/server mib documents

Hi,

see below...

Wijnen, Bert (Bert) wrote:

> Inline
> 
> 
>>-----Original Message-----
>>From: Nelson, David [mailto:[email-masked]]
>>Sent: Friday, March 03, 2006 16:40
>>To: Wijnen, Bert (Bert); [email-masked]
>>Subject: RE: AD review: radius dynauth client/server mib documents
>>
>>
>>Bert Wijnen writes...
>>
>>
>>>2. The a whole serioes of Counter32 objects.
>>>   I wonder what the object is to indicate a counter-discontinuity?
>>>   Or can such only happen at system restart/reboot?
>>>   See RFC2578 that explains this in sect 7.1.6
>>>   RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.
>>
>>RFC2578 Section 7.1.6:
>>
>>   The Counter32 type represents a non-negative integer which
>>   monotonically increases until it reaches a maximum value of 2^32-1
>>   (4294967295 decimal), when it wraps around and starts increasing
>>   again from zero.
>>
>>   Counters have no defined "initial" value, and thus, a 
>>single value of
>>   a Counter has (in general) no information content.  Discontinuities
>>   in the monotonically increasing value normally occur at re-
>>   initialization of the management system, and at other times as
>>   specified in the description of an object-type using this 
>>ASN.1 type.
>>   If such other times can occur, for example, the creation 
>>of an object
>>   instance at times other than re-initialization, then a 
>>corresponding
>>   object should be defined, with an appropriate SYNTAX clause, to
>>   indicate the last discontinuity.  Examples of appropriate SYNTAX
>>   clause include:  TimeStamp (a textual convention defined in [3]),
>>   DateAndTime (another textual convention from [3]) or TimeTicks.
>>
>>RFC4181 Section 4.6.1.2 (1st bullet):
>>
>>   - It is OK to use Counter32/64 for counters that may/will be reset
>>     when the management subsystem is re-initialized or when other
>>     unusual/irregular events occur (e.g., counters 
>>maintained on a line
>>     card may be reset when the line card is reset).  
>>However, if it is
>>     possible for such other unusual/irregular events to occur, the
>>     DESCRIPTION clause MUST state that this is so and MUST describe
>>     those other unusual/irregular events in sufficient detail that it
>>     is possible for a management application to determine whether a
>>     reset has occurred since the last time the counter was 
>>polled.  The
>>     RECOMMENDED way to do this is to provide a discontinuity 
>>indicator
>>     as described in RFC 2578 Sections 7.1.6 and 7.1.10.  For 
>>an example
>>     of such a discontinuity indicator, see the
>>     ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
>>
>>So I take it that the normal wrapping from maximum value to 
>>zero is OK,
>>and reset upon system (re)initialization is OK, but any other
>>"discontinuity" needs special attention.  Is that right? 
>>
> 
> Yes, and that is why I had a very simple solution proposed later in
> my review message. By adding that sentence, we make it clear that
> we have thought about this and that such is indeed the case (assuming 
> that I got it right). By not saying anything about it, it could
> be an unintended omission.
> 

Ok, I will add a sentence the overview section to mention this. I 
believe this is better than in the MIB itself to avoid repeating the 
same for each object again.

Also the reference to the IANA copy-right web page will be removed.

thanks,
Stefaan

> 
>>>  So, the radiusDynAuthClientAddress needs to specify that 
>>
>>the address
>>is
>>
>>>  formatted according to the value of 
>>
>>radiusDynAuthClientAddressType.
>>
>>>  Also, as far as I can tell, any addressType could be present here,
>>>  so formally, you would need to describe when a dns name has been
>>>  resolved (if it occurs).
>>
>>RADIUS normally deals with IP Addresses, as the RADIUS client needs to
>>be registered with the RADIUS Server by IP Address, so that 
>>the correct
>>shared secret can be used.  It is possible to use DNS with RADIUS
>>clients and servers, if sufficient care is taken to always have an
>>accurate inverse name resolution available, but I believe this is not
>>common practice.
>>
> 
> 
> I think that answer is suffient for me.
> 
> Bert
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 07 Mar 2006 15:42:20 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review of RADIUS Digest -07 Document
Date: Tue, 07 Mar 2006 07:41:37 -0800

A new version of the RADIUS Digest document has been submitted in response 
to IETF last call and IESG DISCUSS comments.  Until the specification ends 
up on the archive, it is available here:

http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-07.txt

When it ends up on the archive, it will be available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-07.txt

Please examine this new version of the document to see whether it addresses 
the open issues, which were filed on the RADEXT WG issues list:
http://www.drizzle.com/~aboba/RADEXT/

These include the following:

Issue #             Title                              Owner
----------       -------------------------             
----------------------
150           IANA Considerations            John Loughney
151           Another review                   Kurt Zeilenga
152           Review                              Alexey Melnikov
159           Negotiation                        Wolfgang Beck
162           Nonce Replay Issue             Wolfgang Beck
173           Client Nonce Generation      Sam Hartman
174           Review                              Russ Housley
175           Some NITs                         Bert Wijnen

In particular, the following questions should have been addressed:

* Handling of client/server nonce generation (comments from Sam Hartman, 
Glen Zorn and others)
* Extensibility for new algorithms (Russ Housley)
* Editorial comments (many)

--
to unsubscribe send a message 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, 07 Mar 2006 09:06:42 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: radius dynauth client/server mibs structure
Date: Tue, 7 Mar 2006 06:31:15 +0100 

I think, that I suggested that the doc could get a new revision
after the telechat (so during the week of IETF) and then it could
get approved. We prefer to not let RFC-Editor make these type
of changes. RFC-Editor DOES do MIB SYNTAX check though, but
they do not check if the resuling OID tree is as we expect it
to be.

Bert

> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:[email-masked]]
> Sent: Tuesday, March 07, 2006 05:42
> To: Romascanu, Dan (Dan); Nelson, David; [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: radius dynauth client/server mibs structure
> 
> 
> Agree with Dan. Assume that there would be a trigger to the 
> authors when
> these changes are made to re-check the syntax.
> 
> Thanks
> Nagi
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, March 07, 2006 2:24 AM
> To: Nelson, David; [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: radius dynauth client/server mibs structure
> 
> I have no objection, but I am slightly uneasy with changes in the MIB
> module being made by the RFC Editor. Maybe they are checking 
> the syntax
> as well, but to be on the safe side I recommend that after 
> the change is
> performed the authors extract the MIB text from the draft 
> submitted for
> verification by the RFC Editor and re-check the syntax using the
> recommended tools. 
> 
> Regards,
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Nelson, David
> > Sent: Monday, March 06, 2006 10:45 PM
> > To: [email-masked]
> > Cc: Wijnen, Bert (Bert)
> > Subject: RE: radius dynauth client/server mibs structure
> > 
> > Bert Wijnen writes...
> > 
> > (Suggesting a mechanism for addressing the comments from Juergen 
> > Schoenwalder and himself.)
> > 
> > > Let me see, the RFC-Editor note (for each MIB) would read 
> something
> > aka
> > > 
> > > OLD:
> > >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
> > >                                          {
> > radiusDynAuthServerMIB 1 }
> > > 
> > >    radiusDynAuthServer           OBJECT IDENTIFIER ::=
> > >                                   {
> > radiusDynAuthServerMIBObjects 1 }
> > > 
> > >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> > >          SYNTAX Counter32
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                "The number of Disconnect-Request packets
> > received from
> > >                 unknown addresses."
> > >          ::= { radiusDynAuthServer 1 }
> > > 
> > >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> > >          SYNTAX Counter32
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                "The number of CoA-Request packets received from
> > unknown
> > >                 addresses."
> > >          ::= { radiusDynAuthServer 2 }
> > > 
> > >    radiusDynAuthServerIdentifier OBJECT-TYPE
> > >          SYNTAX SnmpAdminString
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                 "The NAS-Identifier of the RADIUS Dynamic
> > Authorization
> > >                  Server. This is not necessarily the same 
> as sysName
> > in
> > >                  MIB II."
> > >          REFERENCE
> > >                 "RFC 2865, Section 5.32, NAS-Identifier."
> > >          ::= { radiusDynAuthServer 3 }
> > > 
> > >    radiusDynAuthClientTable OBJECT-TYPE
> > >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> > >          MAX-ACCESS not-accessible
> > >          STATUS     current
> > >          DESCRIPTION
> > >                "The (conceptual) table listing the RADIUS Dynamic
> > >                 Authorization Clients with which the 
> server shares a
> > >                 secret."
> > >          ::= { radiusDynAuthServer 4 }
> > > 
> > > NEW:
> > >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
> > >                                          {
> > radiusDynAuthServerMIB 1 }
> > > 
> > > >  radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=
> > >                                   {
> > radiusDynAuthServerMIBObjects 1 }
> > > 
> > >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> > >          SYNTAX Counter32
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                "The number of Disconnect-Request packets
> > received from
> > >                 unknown addresses."
> > > >        ::= { radiusDynAuthServerScalars 1 }
> > > 
> > >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> > >          SYNTAX Counter32
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                "The number of CoA-Request packets received from
> > unknown
> > >                 addresses."
> > > >        ::= { radiusDynAuthServerScalars 2 }
> > > 
> > >    radiusDynAuthServerIdentifier OBJECT-TYPE
> > >          SYNTAX SnmpAdminString
> > >          MAX-ACCESS read-only
> > >          STATUS current
> > >          DESCRIPTION
> > >                 "The NAS-Identifier of the RADIUS Dynamic
> > Authorization
> > >                  Server. This is not necessarily the same 
> as sysName
> > in
> > >                  MIB II."
> > >          REFERENCE
> > >                 "RFC 2865, Section 5.32, NAS-Identifier."
> > > >        ::= { radiusDynAuthServerScalars 3 }
> > > 
> > >    radiusDynAuthClientTable OBJECT-TYPE
> > >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> > >          MAX-ACCESS not-accessible
> > >          STATUS     current
> > >          DESCRIPTION
> > >                "The (conceptual) table listing the RADIUS Dynamic
> > >                 Authorization Clients with which the 
> server shares a
> > >                 secret."
> > > >        ::= { radiusDynAuthServerMIBObjects 2 }
> > 
> > It has been noted that this is a simple change to make 
> before issuing 
> > the RFC, and before there are implementations in the field.
> > 
> > Is there any objection among the members of the WG to resolving the 
> > O&M Area Directorate comments on these documents, as shown?
> > 
> > Upon hearing no objections, the changes will be applied.  
> > Please respond prior to March 16 (the IESG Telechat at which these 
> > documents are likely to be discussed).
> > 
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' 
> in a single
> 
> > line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 07 Mar 2006 04:42:48 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Tue, 7 Mar 2006 10:12:14 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Agree with Dan. Assume that there would be a trigger to the authors when
these changes are made to re-check the syntax.

Thanks
Nagi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, March 07, 2006 2:24 AM
To: Nelson, David; [email-masked]
Cc: Wijnen, Bert (Bert)
Subject: RE: radius dynauth client/server mibs structure

I have no objection, but I am slightly uneasy with changes in the MIB
module being made by the RFC Editor. Maybe they are checking the syntax
as well, but to be on the safe side I recommend that after the change is
performed the authors extract the MIB text from the draft submitted for
verification by the RFC Editor and re-check the syntax using the
recommended tools.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, March 06, 2006 10:45 PM
> To: [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: radius dynauth client/server mibs structure
>=20
> Bert Wijnen writes...
>=20
> (Suggesting a mechanism for addressing the comments from Juergen=20
> Schoenwalder and himself.)
>=20
> > Let me see, the RFC-Editor note (for each MIB) would read something
> aka
> >=20
> > OLD:
> >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
> >                                          {
> radiusDynAuthServerMIB 1 }
> >=20
> >    radiusDynAuthServer           OBJECT IDENTIFIER ::=3D
> >                                   {
> radiusDynAuthServerMIBObjects 1 }
> >=20
> >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of Disconnect-Request packets
> received from
> >                 unknown addresses."
> >          ::=3D { radiusDynAuthServer 1 }
> >=20
> >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of CoA-Request packets received from
> unknown
> >                 addresses."
> >          ::=3D { radiusDynAuthServer 2 }
> >=20
> >    radiusDynAuthServerIdentifier OBJECT-TYPE
> >          SYNTAX SnmpAdminString
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                 "The NAS-Identifier of the RADIUS Dynamic
> Authorization
> >                  Server. This is not necessarily the same as sysName
> in
> >                  MIB II."
> >          REFERENCE
> >                 "RFC 2865, Section 5.32, NAS-Identifier."
> >          ::=3D { radiusDynAuthServer 3 }
> >=20
> >    radiusDynAuthClientTable OBJECT-TYPE
> >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> >          MAX-ACCESS not-accessible
> >          STATUS     current
> >          DESCRIPTION
> >                "The (conceptual) table listing the RADIUS Dynamic
> >                 Authorization Clients with which the server shares a
> >                 secret."
> >          ::=3D { radiusDynAuthServer 4 }
> >=20
> > NEW:
> >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
> >                                          {
> radiusDynAuthServerMIB 1 }
> >=20
> > >  radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=3D
> >                                   {
> radiusDynAuthServerMIBObjects 1 }
> >=20
> >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of Disconnect-Request packets
> received from
> >                 unknown addresses."
> > >        ::=3D { radiusDynAuthServerScalars 1 }
> >=20
> >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of CoA-Request packets received from
> unknown
> >                 addresses."
> > >        ::=3D { radiusDynAuthServerScalars 2 }
> >=20
> >    radiusDynAuthServerIdentifier OBJECT-TYPE
> >          SYNTAX SnmpAdminString
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                 "The NAS-Identifier of the RADIUS Dynamic
> Authorization
> >                  Server. This is not necessarily the same as sysName
> in
> >                  MIB II."
> >          REFERENCE
> >                 "RFC 2865, Section 5.32, NAS-Identifier."
> > >        ::=3D { radiusDynAuthServerScalars 3 }
> >=20
> >    radiusDynAuthClientTable OBJECT-TYPE
> >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> >          MAX-ACCESS not-accessible
> >          STATUS     current
> >          DESCRIPTION
> >                "The (conceptual) table listing the RADIUS Dynamic
> >                 Authorization Clients with which the server shares a
> >                 secret."
> > >        ::=3D { radiusDynAuthServerMIBObjects 2 }
>=20
> It has been noted that this is a simple change to make before issuing=20
> the RFC, and before there are implementations in the field.
>=20
> Is there any objection among the members of the WG to resolving the=20
> O&M Area Directorate comments on these documents, as shown?
>=20
> Upon hearing no objections, the changes will be applied. =20
> Please respond prior to March 16 (the IESG Telechat at which these=20
> documents are likely to be discussed).
>=20
>=20
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in a single

> line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

--
to unsubscribe send a message 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, 06 Mar 2006 21:23:26 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 6 Mar 2006 16:23:18 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>

Juergen Schoenwaelder writes...
=20
> I find the OLD / NEW format extremey difficult to read.

<snip>

> I assume this is what your OLD/NEW editing instructions try to achieve
> for the server MIB.

The RFC Editor has its own preferences for readability, which dictate
the OLD/NEW format.  YMMV.  :-)

--
to unsubscribe send a message 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, 06 Mar 2006 21:19:42 +0000
Date: Mon, 6 Mar 2006 22:20:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Re: radius dynauth client/server mibs structure
Reply-To: [email-masked]
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>

On Mon, Mar 06, 2006 at 03:44:37PM -0500, Nelson, David wrote:
 
> (Suggesting a mechanism for addressing the comments from Juergen
> Schoenwalder and himself.)

[...]

I find the OLD / NEW format extremey difficult to read. The change
being discussed I think is the following (good old unified context
diff format):

--- RADIUS-DYNAUTH-CLIENT-MIB	2006-03-06 22:10:08.000000000 +0100
+++ RADIUS-DYNAUTH-CLIENT-MIB.new	2006-03-06 22:14:00.000000000 +0100
@@ -63,7 +63,7 @@
 radiusDynAuthClientMIBObjects OBJECT IDENTIFIER ::=
                                       { radiusDynAuthClientMIB 1 }
 
-radiusDynAuthClient           OBJECT IDENTIFIER ::=
+radiusDynAuthClientScalars    OBJECT IDENTIFIER ::=
                                { radiusDynAuthClientMIBObjects 1 }
 
 radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE
@@ -73,7 +73,7 @@
        DESCRIPTION
              "The number of Disconnect-Ack and Disconnect-NAK packets
               received from unknown addresses."
-       ::= { radiusDynAuthClient 1 }
+       ::= { radiusDynAuthClientScalars 1 }
 
 radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE
        SYNTAX Counter32
@@ -82,7 +82,7 @@
        DESCRIPTION
              "The number of CoA-Ack and CoA-NAK packets received from
               unknown addresses."
-       ::= { radiusDynAuthClient 2 }
+       ::= { radiusDynAuthClientScalars 2 }
 
 radiusDynAuthServerTable OBJECT-TYPE
        SYNTAX SEQUENCE OF RadiusDynAuthServerEntry
@@ -92,7 +92,7 @@
              "The (conceptual) table listing the RADIUS Dynamic
               Authorization Servers with which the client shares a
               secret."
-       ::= { radiusDynAuthClient 3 }
+       ::= { radiusDynAuthClientMIBObjects 2 }
 
 radiusDynAuthServerEntry OBJECT-TYPE

--- RADIUS-DYNAUTH-SERVER-MIB	2006-03-06 22:11:08.000000000 +0100
+++ RADIUS-DYNAUTH-SERVER-MIB.new	2006-03-06 22:13:48.000000000 +0100
@@ -62,7 +62,7 @@
 radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
                                       { radiusDynAuthServerMIB 1 }
 
-radiusDynAuthServer           OBJECT IDENTIFIER ::=
+radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=
                                { radiusDynAuthServerMIBObjects 1 }
 
 radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
@@ -72,7 +72,7 @@
       DESCRIPTION
             "The number of Disconnect-Request packets received from
              unknown addresses."
-      ::= { radiusDynAuthServer 1 }
+      ::= { radiusDynAuthServerScalars 1 }
 
 radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
       SYNTAX Counter32
@@ -81,7 +81,7 @@
       DESCRIPTION
             "The number of CoA-Request packets received from unknown
              addresses."
-      ::= { radiusDynAuthServer 2 }
+      ::= { radiusDynAuthServerScalars 2 }
 
 radiusDynAuthServerIdentifier OBJECT-TYPE
       SYNTAX SnmpAdminString
@@ -93,7 +93,7 @@
               MIB II."
       REFERENCE
              "RFC 2865, Section 5.32, NAS-Identifier."
-      ::= { radiusDynAuthServer 3 }
+      ::= { radiusDynAuthServerScalars 3 }

 
@@ -106,7 +106,7 @@
             "The (conceptual) table listing the RADIUS Dynamic
              Authorization Clients with which the server shares a
              secret."
-      ::= { radiusDynAuthServer 4 }
+      ::= { radiusDynAuthServerMIBObjects 2 }
 
 radiusDynAuthClientEntry OBJECT-TYPE
        SYNTAX     RadiusDynAuthClientEntry

I assume this is what your OLD/NEW editing instructions try to achieve
for the server MIB.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message 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, 06 Mar 2006 20:54:08 +0000
content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 6 Mar 2006 22:53:57 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

I have no objection, but I am slightly uneasy with changes in the MIB
module being made by the RFC Editor. Maybe they are checking the syntax
as well, but to be on the safe side I recommend that after the change is
performed the authors extract the MIB text from the draft submitted for
verification by the RFC Editor and re-check the syntax using the
recommended tools.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, March 06, 2006 10:45 PM
> To: [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: radius dynauth client/server mibs structure
>=20
> Bert Wijnen writes...
>=20
> (Suggesting a mechanism for addressing the comments from=20
> Juergen Schoenwalder and himself.)
>=20
> > Let me see, the RFC-Editor note (for each MIB) would read something
> aka
> >=20
> > OLD:
> >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
> >                                          {=20
> radiusDynAuthServerMIB 1 }
> >=20
> >    radiusDynAuthServer           OBJECT IDENTIFIER ::=3D
> >                                   {=20
> radiusDynAuthServerMIBObjects 1 }
> >=20
> >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of Disconnect-Request packets=20
> received from
> >                 unknown addresses."
> >          ::=3D { radiusDynAuthServer 1 }
> >=20
> >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of CoA-Request packets received from
> unknown
> >                 addresses."
> >          ::=3D { radiusDynAuthServer 2 }
> >=20
> >    radiusDynAuthServerIdentifier OBJECT-TYPE
> >          SYNTAX SnmpAdminString
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                 "The NAS-Identifier of the RADIUS Dynamic
> Authorization
> >                  Server. This is not necessarily the same as sysName
> in
> >                  MIB II."
> >          REFERENCE
> >                 "RFC 2865, Section 5.32, NAS-Identifier."
> >          ::=3D { radiusDynAuthServer 3 }
> >=20
> >    radiusDynAuthClientTable OBJECT-TYPE
> >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> >          MAX-ACCESS not-accessible
> >          STATUS     current
> >          DESCRIPTION
> >                "The (conceptual) table listing the RADIUS Dynamic
> >                 Authorization Clients with which the server shares a
> >                 secret."
> >          ::=3D { radiusDynAuthServer 4 }
> >=20
> > NEW:
> >    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
> >                                          {=20
> radiusDynAuthServerMIB 1 }
> >=20
> > >  radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=3D
> >                                   {=20
> radiusDynAuthServerMIBObjects 1 }
> >=20
> >    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of Disconnect-Request packets=20
> received from
> >                 unknown addresses."
> > >        ::=3D { radiusDynAuthServerScalars 1 }
> >=20
> >    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
> >          SYNTAX Counter32
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                "The number of CoA-Request packets received from
> unknown
> >                 addresses."
> > >        ::=3D { radiusDynAuthServerScalars 2 }
> >=20
> >    radiusDynAuthServerIdentifier OBJECT-TYPE
> >          SYNTAX SnmpAdminString
> >          MAX-ACCESS read-only
> >          STATUS current
> >          DESCRIPTION
> >                 "The NAS-Identifier of the RADIUS Dynamic
> Authorization
> >                  Server. This is not necessarily the same as sysName
> in
> >                  MIB II."
> >          REFERENCE
> >                 "RFC 2865, Section 5.32, NAS-Identifier."
> > >        ::=3D { radiusDynAuthServerScalars 3 }
> >=20
> >    radiusDynAuthClientTable OBJECT-TYPE
> >          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
> >          MAX-ACCESS not-accessible
> >          STATUS     current
> >          DESCRIPTION
> >                "The (conceptual) table listing the RADIUS Dynamic
> >                 Authorization Clients with which the server shares a
> >                 secret."
> > >        ::=3D { radiusDynAuthServerMIBObjects 2 }
>=20
> It has been noted that this is a simple change to make before=20
> issuing the RFC, and before there are implementations in the field.
>=20
> Is there any objection among the members of the WG to=20
> resolving the O&M Area Directorate comments on these=20
> documents, as shown?
>=20
> Upon hearing no objections, the changes will be applied. =20
> Please respond prior to March 16 (the IESG Telechat at which=20
> these documents are likely to be discussed).
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 06 Mar 2006 20:44:50 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Mon, 6 Mar 2006 15:44:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Bert Wijnen writes...

(Suggesting a mechanism for addressing the comments from Juergen
Schoenwalder and himself.)

> Let me see, the RFC-Editor note (for each MIB) would read something
aka
>=20
> OLD:
>    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
>                                          { radiusDynAuthServerMIB 1 }
>=20
>    radiusDynAuthServer           OBJECT IDENTIFIER ::=3D
>                                   { radiusDynAuthServerMIBObjects 1 }
>=20
>    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of Disconnect-Request packets received from
>                 unknown addresses."
>          ::=3D { radiusDynAuthServer 1 }
>=20
>    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of CoA-Request packets received from
unknown
>                 addresses."
>          ::=3D { radiusDynAuthServer 2 }
>=20
>    radiusDynAuthServerIdentifier OBJECT-TYPE
>          SYNTAX SnmpAdminString
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                 "The NAS-Identifier of the RADIUS Dynamic
Authorization
>                  Server. This is not necessarily the same as sysName
in
>                  MIB II."
>          REFERENCE
>                 "RFC 2865, Section 5.32, NAS-Identifier."
>          ::=3D { radiusDynAuthServer 3 }
>=20
>    radiusDynAuthClientTable OBJECT-TYPE
>          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
>          MAX-ACCESS not-accessible
>          STATUS     current
>          DESCRIPTION
>                "The (conceptual) table listing the RADIUS Dynamic
>                 Authorization Clients with which the server shares a
>                 secret."
>          ::=3D { radiusDynAuthServer 4 }
>=20
> NEW:
>    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D
>                                          { radiusDynAuthServerMIB 1 }
>=20
> >  radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=3D
>                                   { radiusDynAuthServerMIBObjects 1 }
>=20
>    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of Disconnect-Request packets received from
>                 unknown addresses."
> >        ::=3D { radiusDynAuthServerScalars 1 }
>=20
>    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of CoA-Request packets received from
unknown
>                 addresses."
> >        ::=3D { radiusDynAuthServerScalars 2 }
>=20
>    radiusDynAuthServerIdentifier OBJECT-TYPE
>          SYNTAX SnmpAdminString
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                 "The NAS-Identifier of the RADIUS Dynamic
Authorization
>                  Server. This is not necessarily the same as sysName
in
>                  MIB II."
>          REFERENCE
>                 "RFC 2865, Section 5.32, NAS-Identifier."
> >        ::=3D { radiusDynAuthServerScalars 3 }
>=20
>    radiusDynAuthClientTable OBJECT-TYPE
>          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
>          MAX-ACCESS not-accessible
>          STATUS     current
>          DESCRIPTION
>                "The (conceptual) table listing the RADIUS Dynamic
>                 Authorization Clients with which the server shares a
>                 secret."
> >        ::=3D { radiusDynAuthServerMIBObjects 2 }

It has been noted that this is a simple change to make before issuing
the RFC, and before there are implementations in the field.

Is there any objection among the members of the WG to resolving the O&M
Area Directorate comments on these documents, as shown?

Upon hearing no objections, the changes will be applied.  Please respond
prior to March 16 (the IESG Telechat at which these documents are likely
to be discussed).

--
to unsubscribe send a message 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, 06 Mar 2006 20:35:31 +0000
Content-class: urn:content-classes:message
Subject: RE: AD review: radius dynauth client/server mib documents
Date: Mon, 6 Mar 2006 15:35:00 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Bert Wijnen  writes...

> Yes, and that is why I had a very simple solution proposed later in
> my review message. By adding that sentence, we make it clear that
> we have thought about this and that such is indeed the case (assuming
> that I got it right). By not saying anything about it, it could
> be an unintended omission.

Is there any objection among the WG members to resolve the AD comment by
adding text that clarifies that discontinuities the values of these
counters will only occur upon counter wrap from maximum value to zero
and upon (re)initialization of the managed entity?

Upon hearing no objection, the clarification will be added.

--
to unsubscribe send a message 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, 06 Mar 2006 18:31:25 +0000
Content-class: urn:content-classes:message
Subject: Issue: Vlan-00 allowing hints in request messages
Date: Mon, 6 Mar 2006 10:30:46 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

Submitter name: Mauricio Sanchez
Submitter email address: [email-masked]
Date first submitted: March 6, 2006
Reference:=20
Document: draft-ietf-radext-vlan-00.txt
Comment type: T
Priority: 2
Section: Table in section 3, individual attributes
Rationale/Explanation of issue: Draft-ietf-radext-vlan-00 does not allow
the new attributes to be sent in ACCESS-REQUEST messages.  If allowed,
attributes in the REQUEST message could serve as 'hints' to the RADIUS
server during the decision making process.=20
Requested change:  Allow attributes to be sent ACCESS-REQUEST message
Proposed changes to the document.=20

- Descriptions of individual attribute descriptions would be changed to
allow attributes in access request, as follows:
Multiple <attr_name> attributes MAY be included in an Access-Request,
Access-Accept or CoA-Request packet; this attribute MUST NOT be sent
within an Access-Challenge, Access-Reject, Disconnect-Request,
Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.

-Table in section 3 would be changed to:

   Access-   Access-  Access-  Access-    CoA-
   Request   Accept   Reject   Challenge  Req     #    Attribute
       0+      0+       0        0        0+    TBD  Egress-VLANID
       0-1     0-1      0        0        0-1   TBD  Ingress-Filters
       0+      0+       0        0        0+    TBD  Egress-VLAN-Name
       0-1     0-1      0        0        0-1   TBD  User-Priority-Table

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

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

Delivery-date: Fri, 03 Mar 2006 23:23:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Update on RADIUS Digest Issues?
Date: Fri, 03 Mar 2006 15:22:50 -0800

Can we get an update on where we are with respect to the open issue on the 
RADIUS Digest document?  The ADs have inquired about where we are and what 
issues are still open.

--
to unsubscribe send a message 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, 03 Mar 2006 21:27:03 +0000
Content-class: urn:content-classes:message
Subject: [Issue 168] split-out filter draft: IANA
Date: Fri, 3 Mar 2006 16:27:58 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

I see that draft-ietf-radext-filter-rules-00.txt fixes
most of the editorial comments I made as part of issue
168.  I guess we can close this issue if the authors will
just agree to fix this (at some point):

 - The IANA section says the draft is allocating six
   attributes, but it's only allocating two.

Greg

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

Delivery-date: Fri, 03 Mar 2006 20:38:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  RADEXT WG Last Call on VLAN and Priority Attributes Document
Date: Fri, 03 Mar 2006 12:38:13 -0800

There is an ongoing RADEXT WG last call on the VLAN and Priority Attributes 
document,
prior to sending it on to the IESG for consideration as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt

RADEXT WG last call will last until Friday, March 17, 2006. Please send your
comments to the RADEXT WG mailing list ([email-masked]) in the format
described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Since all RADEXT WG last calls require at least 5 reviewers in order to 
advance
the document, please respond indicating that you have read the document and
find it acceptable, even if you have no issues to file.

--
to unsubscribe send a message 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, 03 Mar 2006 20:12:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Fri, 03 Mar 2006 12:12:43 -0800

This is an announcement of RADEXT WG last call on the "RADIUS Delegated-IPv6 
Prefix Attribute"
document, prior to sending this document on to the IESG for consideration as 
a Proposed
Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt

RADEXT WG last call will last until Monday March 27, 2006.  Please send your
comments to the RADEXT WG list ([email-masked]) in the format 
described
on the RADEXT Issues List:
http://www.drizzle.com/~aboba/RADEXT/

Since all RADEXT WG last calls require at least 5 reviewers in order to 
advance
the document, please respond indicating that you have read the document and
find it acceptable, even if you have no issues to file.

--
to unsubscribe send a message 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, 03 Mar 2006 20:02:53 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Fri, 03 Mar 2006 12:02:14 -0800

This is an announcement of RADEXT WG last call on the "RADIUS Delegated-IPv6 
Prefix Attribute"
document, prior to sending this document on to the IESG for consideration as 
a Proposed
Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt

RADEXT WG last call will last until Monday March 27, 2006.  Please send your
comments to the RADEXT WG list ([email-masked]) in the format 
described
on the RADEXT Issues List:
http://www.drizzle.com/~aboba/RADEXT/

Since all RADEXT WG last calls require at least 5 reviewers in order to 
advance
the document, please respond indicating that you have read the document and
find it acceptable, even if you have no issues to file.

--
to unsubscribe send a message 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, 03 Mar 2006 16:03:18 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: radius dynauth client/server mibs structure
Date: Fri, 3 Mar 2006 17:02:47 +0100 

Inline

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 16:45
> To: Wijnen, Bert (Bert); Nagi Reddy Jonnala (njonnala);
> [email-masked]; [email-masked]
> Subject: RE: radius dynauth client/server mibs structure
> 
> 
> Bert Wijnen writes...
> 
> > The disadvantage of not doing so is in the future when 
> adding scalars
> > and thing not having grouped as nicely and so more complexity.
> 
> In practice, does this inconvenient grouping really affect any SNMP
> applications in a user-visible way, except for MIB-walk and 
> MIB-browser applications?
> 

I know from experience that it made it easier for me to implement the
MIB at the agent side. Of course that could have been caused just by my
owb design, and other may not have trouble with it at all.

I am somewhat less familiar with mgmt apps.

> > This is not a blocking comment, just another MIB-type person believing
> > that the change would be real EASY now, and it will certainly make
> > things cleaner/easier in the future.
> 
> It certainly makes the MIB _document_ neater.
> 

And rigth now (at FIRST or INITIAL version) it is EASY to make the change
to make something neat. Later you cannot correct it without possibly
deprecating/obsoleteing existing and adding new objects.

Oh well.

Bert

--
to unsubscribe send a message 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, 03 Mar 2006 16:03:12 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: AD review: radius dynauth client/server mib documents
Date: Fri, 3 Mar 2006 17:02:47 +0100 

Inline

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 16:40
> To: Wijnen, Bert (Bert); [email-masked]
> Subject: RE: AD review: radius dynauth client/server mib documents
> 
> 
> Bert Wijnen writes...
> 
> > 2. The a whole serioes of Counter32 objects.
> >    I wonder what the object is to indicate a counter-discontinuity?
> >    Or can such only happen at system restart/reboot?
> >    See RFC2578 that explains this in sect 7.1.6
> >    RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.
> 
> RFC2578 Section 7.1.6:
> 
>    The Counter32 type represents a non-negative integer which
>    monotonically increases until it reaches a maximum value of 2^32-1
>    (4294967295 decimal), when it wraps around and starts increasing
>    again from zero.
> 
>    Counters have no defined "initial" value, and thus, a 
> single value of
>    a Counter has (in general) no information content.  Discontinuities
>    in the monotonically increasing value normally occur at re-
>    initialization of the management system, and at other times as
>    specified in the description of an object-type using this 
> ASN.1 type.
>    If such other times can occur, for example, the creation 
> of an object
>    instance at times other than re-initialization, then a 
> corresponding
>    object should be defined, with an appropriate SYNTAX clause, to
>    indicate the last discontinuity.  Examples of appropriate SYNTAX
>    clause include:  TimeStamp (a textual convention defined in [3]),
>    DateAndTime (another textual convention from [3]) or TimeTicks.
> 
> RFC4181 Section 4.6.1.2 (1st bullet):
> 
>    - It is OK to use Counter32/64 for counters that may/will be reset
>      when the management subsystem is re-initialized or when other
>      unusual/irregular events occur (e.g., counters 
> maintained on a line
>      card may be reset when the line card is reset).  
> However, if it is
>      possible for such other unusual/irregular events to occur, the
>      DESCRIPTION clause MUST state that this is so and MUST describe
>      those other unusual/irregular events in sufficient detail that it
>      is possible for a management application to determine whether a
>      reset has occurred since the last time the counter was 
> polled.  The
>      RECOMMENDED way to do this is to provide a discontinuity 
> indicator
>      as described in RFC 2578 Sections 7.1.6 and 7.1.10.  For 
> an example
>      of such a discontinuity indicator, see the
>      ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
> 
> So I take it that the normal wrapping from maximum value to 
> zero is OK,
> and reset upon system (re)initialization is OK, but any other
> "discontinuity" needs special attention.  Is that right? 
> 
Yes, and that is why I had a very simple solution proposed later in
my review message. By adding that sentence, we make it clear that
we have thought about this and that such is indeed the case (assuming 
that I got it right). By not saying anything about it, it could
be an unintended omission.

> >   So, the radiusDynAuthClientAddress needs to specify that 
> the address
> is
> >   formatted according to the value of 
> radiusDynAuthClientAddressType.
> >   Also, as far as I can tell, any addressType could be present here,
> >   so formally, you would need to describe when a dns name has been
> >   resolved (if it occurs).
> 
> RADIUS normally deals with IP Addresses, as the RADIUS client needs to
> be registered with the RADIUS Server by IP Address, so that 
> the correct
> shared secret can be used.  It is possible to use DNS with RADIUS
> clients and servers, if sufficient care is taken to always have an
> accurate inverse name resolution available, but I believe this is not
> common practice.
> 

I think that answer is suffient for me.

Bert

--
to unsubscribe send a message 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, 03 Mar 2006 15:44:47 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Fri, 3 Mar 2006 10:44:41 -0500
From: "Nelson, David" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bert Wijnen writes...

> The disadvantage of not doing so is in the future when adding scalars
> and thing not having grouped as nicely and so more complexity.

In practice, does this inconvenient grouping really affect any SNMP
applications in a user-visible way, except for MIB-walk and MIB-browser
applications?

> This is not a blocking comment, just another MIB-type person believing
> that the change would be real EASY now, and it will certainly make
> things cleaner/easier in the future.

It certainly makes the MIB _document_ neater.

--
to unsubscribe send a message 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, 03 Mar 2006 15:40:40 +0000
Content-class: urn:content-classes:message
Subject: RE: AD review: radius dynauth client/server mib documents
Date: Fri, 3 Mar 2006 10:40:20 -0500
From: "Nelson, David" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

Bert Wijnen writes...

> 2. The a whole serioes of Counter32 objects.
>    I wonder what the object is to indicate a counter-discontinuity?
>    Or can such only happen at system restart/reboot?
>    See RFC2578 that explains this in sect 7.1.6
>    RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.

RFC2578 Section 7.1.6:

   The Counter32 type represents a non-negative integer which
   monotonically increases until it reaches a maximum value of 2^32-1
   (4294967295 decimal), when it wraps around and starts increasing
   again from zero.

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity.  Examples of appropriate SYNTAX
   clause include:  TimeStamp (a textual convention defined in [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

RFC4181 Section 4.6.1.2 (1st bullet):

   - It is OK to use Counter32/64 for counters that may/will be reset
     when the management subsystem is re-initialized or when other
     unusual/irregular events occur (e.g., counters maintained on a line
     card may be reset when the line card is reset).  However, if it is
     possible for such other unusual/irregular events to occur, the
     DESCRIPTION clause MUST state that this is so and MUST describe
     those other unusual/irregular events in sufficient detail that it
     is possible for a management application to determine whether a
     reset has occurred since the last time the counter was polled.  The
     RECOMMENDED way to do this is to provide a discontinuity indicator
     as described in RFC 2578 Sections 7.1.6 and 7.1.10.  For an example
     of such a discontinuity indicator, see the
     ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].

So I take it that the normal wrapping from maximum value to zero is OK,
and reset upon system (re)initialization is OK, but any other
"discontinuity" needs special attention.  Is that right?=20

>   So, the radiusDynAuthClientAddress needs to specify that the address
is
>   formatted according to the value of radiusDynAuthClientAddressType.
>   Also, as far as I can tell, any addressType could be present here,
>   so formally, you would need to describe when a dns name has been
>   resolved (if it occurs).

RADIUS normally deals with IP Addresses, as the RADIUS client needs to
be registered with the RADIUS Server by IP Address, so that the correct
shared secret can be used.  It is possible to use DNS with RADIUS
clients and servers, if sufficient care is taken to always have an
accurate inverse name resolution available, but I believe this is not
common practice.

--
to unsubscribe send a message 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, 03 Mar 2006 15:14:45 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: AD review: radius dynauth client/server mib documents
Date: Fri, 3 Mar 2006 16:13:49 +0100 

1. In the MIB MODULE IDENTITY DESCRIPTION clause it says:

          DESCRIPTION
              "The MIB module for entities implementing the server
               side of the Dynamic Authorization Extensions to Remote
               Authentication Dial In User Service (RADIUS) protocol.

               Copyright (C) The Internet Society (2005).  Initial
               version as published in RFC yyyy;
               for full legal notices see the RFC itself.  Supplementary
               information may be available on
               http://www.ietf.org/copyrights/ianamib.html."

   That last sentence is NOT applicable. There is nothing in this MIB
   module that is mainatined by IANA, so their copy-right web page is
   not relevant. Fix is to just remove last sentence.

2. The a whole serioes of Counter32 objects.
   I wonder what the object is to indicate a counter-discontinuity?
   Or can such only happen at system restart/reboot?
   See RFC2578 that explains this in sect 7.1.6
   RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.

3. I see
   radiusDynAuthClientAddressType OBJECT-TYPE
          SYNTAX     InetAddressType
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The type of IP address of the RADIUS Dynamic
                 Authorization Client referred to in this table entry."
          ::= { radiusDynAuthClientEntry 2 }

   radiusDynAuthClientAddress OBJECT-TYPE
          SYNTAX     InetAddress
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The IP address value of the RADIUS Dynamic
                 Authorization Client referred to in this table entry,
                 using the version neutral IP address format."
          ::= { radiusDynAuthClientEntry 3 }

  So, the radiusDynAuthClientAddress needs to specify that the address is 
  formatted according to the value of radiusDynAuthClientAddressType.
  Also, as far as I can tell, any addressType could be present here,
  so formally, you would need to describe when a dns name has been
  resolved (if it occurs). 

Same for both MIB documents.

Point 1 I can do with an RFC-Editor note.
Point 2 I can also address with an RFC-Editor not if the intend (default)
        is that a dsiscuntinuity can only occur at system re-initiatlization.
        If so, I suggest to add an entry to the DESCRIPTION clause of the
        table itself that states:

            Discontinuities for all counter32 objects in this table can
            only occur at system re-initialization. 
            So no specific discontinuity onjects have been defined.
Point 3 Mmm... I guess there will only be ipv4 or ipv6 addresses.
        If so, I can live with it since this is a read-only MIB module
        and the doc is Informational.

Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Friday, March 03, 2006 15:36
> To: 'Nagi Reddy Jonnala (njonnala)'; [email-masked];
> [email-masked]
> Subject: RE: radius dynauth client/server mibs structure
> 
> 
> Are there implementations already? 
> If not, I would also recommend to make the change suggested 
> by Juergen.
> If yes, even then the suggested change is still simple now.
> 
> The disadvantage of not doing so is in the future when adding scalars
> and thing not having grouped as nicely and so more complexity.
> 
> This is not a blocking comment, just another MIB-type person believing
> that the change would be real EASY now, and it will certainly make
> things cleaner/easier in the future.
> 
> Bert
> 
> > -----Original Message-----
> > From: Nagi Reddy Jonnala (njonnala) [mailto:[email-masked]]
> > Sent: Tuesday, February 14, 2006 11:24
> > To: [email-masked]; [email-masked]
> > Cc: Bert Wijnen
> > Subject: RE: radius dynauth client/server mibs structure
> > 
> > 
> > Juergen,
> > 
> > Your comments may be correct. We authors have discussed about your
> > comments and realized that the comments are not directly related to
> > these MIBs but in general whether the scalars should be 
> > grouped together
> > or not. The recommended way can best be addressed in the IETF MIB
> > guidelines. Since there seem to be plenty of MIBs that don't 
> > follow your
> > commented approach, no recommended way in the IETF MIB 
> guidelines and
> > because it is a stylistic change, we leave the MIBs as they are.
> > 
> > Thanks
> > Nagi.
> > 
> >  
> > 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Juergen Schoenwaelder
> > Sent: Thursday, February 09, 2006 12:03 AM
> > To: [email-masked]
> > Cc: Bert Wijnen
> > Subject: radius dynauth client/server mibs structure
> > 
> > Hi,
> > 
> > I took a quick look at the radius dynauth client/server mibs today:
> > 
> >    draft-ietf-radext-dynauth-client-mib-03.txt
> >    draft-ietf-radext-dynauth-server-mib-03.txt
> > 
> > While looking at the OID tree, I came up with the following 
> stylistic
> > change. Currently, the OID tree of the two MIBs basically looks like
> > this (details of the tables and conformance nodes deleted):
> > 
> > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
> >   |
> >   +--radiusDynAuthServerMIBObjects(1)
> >   |  |
> >   |  +--radiusDynAuthServer(1)
> >   |     |
> >   |     +--radiusDynAuthServerDisconInvalidClientAddresses(1)
> >   |     +--radiusDynAuthServerCoAInvalidClientAddresses(2)
> >   |     +--radiusDynAuthServerIdentifier(3)
> >   |     |
> >   |     +--radiusDynAuthClientTable(4)
> >   |
> >   +--radiusDynAuthServerMIBConformance(2)
> > 
> > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
> >   |
> >   +--radiusDynAuthClientMIBObjects(1)
> >   |  |
> >   |  +--radiusDynAuthClient(1)
> >   |     |
> >   |     +--radiusDynAuthClientDisconInvalidServerAddresses(1)
> >   |     +--radiusDynAuthClientCoAInvalidServerAddresses(2)
> >   |     |
> >   |     +--radiusDynAuthServerTable(3)
> >   |
> >   +--radiusDynAuthClientMIBConformance(2)
> > 
> > I was wondering what the value of having the radiusDynAuthServer and
> > radiusDynAuthClient nodes is. I do understand if people 
> like to group
> > related scalars together (so additions are numbered using 
> consecutive
> > identifiers), but then the OID structure should more look like the
> > following:
> > 
> > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
> >   |
> >   +--radiusDynAuthServerMIBObjects(1)
> >   |  |
> >   |  +--radiusDynAuthServerScalars(1)
> >   |  |  |
> >   |  |  +--radiusDynAuthServerDisconInvalidClientAddresses(1)
> >   |  |  +--radiusDynAuthServerCoAInvalidClientAddresses(2)
> >   |  |  +--radiusDynAuthServerIdentifier(3)
> >   |  |
> >   |  +--radiusDynAuthClientTable(2)
> >   |
> >   +--radiusDynAuthServerMIBConformance(2)
> > 
> > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
> >   |
> >   +--radiusDynAuthClientMIBObjects(1)
> >   |  |
> >   |  +--radiusDynAuthClientScalars(1)
> >   |  |  |
> >   |  |  +--radiusDynAuthClientDisconInvalidServerAddresses(1)
> >   |  |  +--radiusDynAuthClientCoAInvalidServerAddresses(2)
> >   |  |
> >   |  +--radiusDynAuthServerTable(2)
> >   |
> >   +--radiusDynAuthClientMIBConformance(2)
> > 
> > The benefit of this change is that you can add scalars later 
> > while keep
> > all the scalars rooted together and consecutively numbered 
> > while in the
> > current scheme you end up to have tables intermixed with 
> scalars over
> > time.
> > 
> > Please note that there is nothing technically wrong with the MIBs as
> > they are right now. My suggestion is purely stylistic and 
> > basically just
> > increases readability in case updates are done in the future.
> > 
> > I am aware that these MIB modules have passed WG last call and MIB
> > review and are in the hands of the ADs and as such I do not 
> > ask to make
> > a change just for stylistic reasons. I just wanted to bring 
> > this to your
> > attention and I like to leave it to the editors/chairs to 
> > decide whether
> > you want to make the relatively simple changes at this point 
> > in time or
> > prefer to go ahead with what you have.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder		    International 
> University Bremen
> > <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> > 28725 Bremen,
> > Germany
> > 
> > --
> > to unsubscribe send a message to 
> > [email-masked] with the
> > word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 

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

Delivery-date: Fri, 03 Mar 2006 14:37:40 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: radius dynauth client/server mibs structure
Date: Fri, 3 Mar 2006 15:36:57 +0100 

Are there implementations already? 
If not, I would also recommend to make the change suggested by Juergen.
If yes, even then the suggested change is still simple now.

The disadvantage of not doing so is in the future when adding scalars
and thing not having grouped as nicely and so more complexity.

This is not a blocking comment, just another MIB-type person believing
that the change would be real EASY now, and it will certainly make
things cleaner/easier in the future.

Bert

> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2006 11:24
> To: [email-masked]; [email-masked]
> Cc: Bert Wijnen
> Subject: RE: radius dynauth client/server mibs structure
> 
> 
> Juergen,
> 
> Your comments may be correct. We authors have discussed about your
> comments and realized that the comments are not directly related to
> these MIBs but in general whether the scalars should be 
> grouped together
> or not. The recommended way can best be addressed in the IETF MIB
> guidelines. Since there seem to be plenty of MIBs that don't 
> follow your
> commented approach, no recommended way in the IETF MIB guidelines and
> because it is a stylistic change, we leave the MIBs as they are.
> 
> Thanks
> Nagi.
> 
>  
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, February 09, 2006 12:03 AM
> To: [email-masked]
> Cc: Bert Wijnen
> Subject: radius dynauth client/server mibs structure
> 
> Hi,
> 
> I took a quick look at the radius dynauth client/server mibs today:
> 
>    draft-ietf-radext-dynauth-client-mib-03.txt
>    draft-ietf-radext-dynauth-server-mib-03.txt
> 
> While looking at the OID tree, I came up with the following stylistic
> change. Currently, the OID tree of the two MIBs basically looks like
> this (details of the tables and conformance nodes deleted):
> 
> --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
>   |
>   +--radiusDynAuthServerMIBObjects(1)
>   |  |
>   |  +--radiusDynAuthServer(1)
>   |     |
>   |     +--radiusDynAuthServerDisconInvalidClientAddresses(1)
>   |     +--radiusDynAuthServerCoAInvalidClientAddresses(2)
>   |     +--radiusDynAuthServerIdentifier(3)
>   |     |
>   |     +--radiusDynAuthClientTable(4)
>   |
>   +--radiusDynAuthServerMIBConformance(2)
> 
> --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
>   |
>   +--radiusDynAuthClientMIBObjects(1)
>   |  |
>   |  +--radiusDynAuthClient(1)
>   |     |
>   |     +--radiusDynAuthClientDisconInvalidServerAddresses(1)
>   |     +--radiusDynAuthClientCoAInvalidServerAddresses(2)
>   |     |
>   |     +--radiusDynAuthServerTable(3)
>   |
>   +--radiusDynAuthClientMIBConformance(2)
> 
> I was wondering what the value of having the radiusDynAuthServer and
> radiusDynAuthClient nodes is. I do understand if people like to group
> related scalars together (so additions are numbered using consecutive
> identifiers), but then the OID structure should more look like the
> following:
> 
> --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
>   |
>   +--radiusDynAuthServerMIBObjects(1)
>   |  |
>   |  +--radiusDynAuthServerScalars(1)
>   |  |  |
>   |  |  +--radiusDynAuthServerDisconInvalidClientAddresses(1)
>   |  |  +--radiusDynAuthServerCoAInvalidClientAddresses(2)
>   |  |  +--radiusDynAuthServerIdentifier(3)
>   |  |
>   |  +--radiusDynAuthClientTable(2)
>   |
>   +--radiusDynAuthServerMIBConformance(2)
> 
> --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
>   |
>   +--radiusDynAuthClientMIBObjects(1)
>   |  |
>   |  +--radiusDynAuthClientScalars(1)
>   |  |  |
>   |  |  +--radiusDynAuthClientDisconInvalidServerAddresses(1)
>   |  |  +--radiusDynAuthClientCoAInvalidServerAddresses(2)
>   |  |
>   |  +--radiusDynAuthServerTable(2)
>   |
>   +--radiusDynAuthClientMIBConformance(2)
> 
> The benefit of this change is that you can add scalars later 
> while keep
> all the scalars rooted together and consecutively numbered 
> while in the
> current scheme you end up to have tables intermixed with scalars over
> time.
> 
> Please note that there is nothing technically wrong with the MIBs as
> they are right now. My suggestion is purely stylistic and 
> basically just
> increases readability in case updates are done in the future.
> 
> I am aware that these MIB modules have passed WG last call and MIB
> review and are in the hands of the ADs and as such I do not 
> ask to make
> a change just for stylistic reasons. I just wanted to bring 
> this to your
> attention and I like to leave it to the editors/chairs to 
> decide whether
> you want to make the relatively simple changes at this point 
> in time or
> prefer to go ahead with what you have.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen,
> Germany
> 
> --
> to unsubscribe send 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, 02 Mar 2006 23:50:36 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-00.txt 
Date: Thu, 02 Mar 2006 18:50:01 -0500

--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 Delegated-IPv6-Prefix Attribute
	Author(s)	: J. Salowey, R. Droms
	Filename	: draft-ietf-radext-delegated-prefix-00.txt
	Pages		: 5
	Date		: 2006-3-2
	
   The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is
   to be delegated to the user.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-delegated-prefix-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-delegated-prefix-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-delegated-prefix-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-delegated-prefix-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--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: Thu, 02 Mar 2006 20:17:54 +0000
Date: Thu, 2 Mar 2006 15:17:10 -0500
From: Barney Wolff <[email-masked]>
To: [email-masked]
Subject: Re: Extended-Space attribute draft available

The draft has now made it to the ietf server:
http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.txt

In response to comments from Glen Zorn and Dave Nelson, any mention
of the imagination, wild or otherwise, of the original designers
will be removed in the next version.

Comments and corrections are still welcome.
Barney

On Mon, Feb 27, 2006 at 09:09:21PM -0500, Barney Wolff wrote:
> Greg Weber and I have written a draft defining an Extended-Space
> attribute.  Here's the abstract:
> 
>    The RADIUS protocol is being extended beyond the wildest imaginations
>    of its original designers.  These extensions are pushing up against
>    the existing limitations on the numbers, length, base types and
>    grouping of RADIUS attributes.  This document specifies a method of
>    relaxing those limitations.
> 
> While it works its way to the IETF draft directory, you're welcome
> to retrieve it here:
> 
> http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt
> http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html
> 
> This draft is a companion piece the the design guidelines draft, and,
> we hope, will be adopted as a RADEXT work item.
> 
> Comments and corrections are welcome, and if necessary I can try to
> get a -01 version in before next week's deadline.

--
to unsubscribe send a message 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, 01 Mar 2006 19:43:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Extended-Space attribute draft available
Date: Wed, 1 Mar 2006 14:41:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...

> Unless we worked at Livingston, I don't think we are the=20
> original designers so how do we know what their wildest=20
> imaginations were?

I agree that the colorful rhetoric about the history of RADIUS in the
abstract could be omitted without any loss of clarity.

> I don't recall when I joined the list, but I did attend
> the BOFs...

I started at the second BOF.  So I remember much of this history...
FWIW.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 01 Mar 2006 18:51:00 +0000
From: "Alan DeKok" <[email-masked]>
To: Barney Wolff <[email-masked]>
Subject: Re: Extended-Space attribute draft available 
cc: [email-masked]
Date: Wed, 01 Mar 2006 13:57:49 -0500
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> Ah, the avp-header debate begins :)

  While there is much temptation to "optimize" the format of the
attribute for packing efficiency, I don't think that's the highest
priority.

> allowing a translating gateway to
> simply do a bulk copy of the concatenated value fields of all the
> Extended-Space attributes in the RADIUS message.

  I strongly prefer re-using the diameter format.  RADIUS servers that
implement Diameter gateways or TTLS will already have code to deal
with that 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: Wed, 01 Mar 2006 06:30:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Extended-Space attribute draft available
Date: Tue, 28 Feb 2006 22:29:59 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> supposedly scribbled:

> On Tue, Feb 28, 2006 at 07:10:35PM -0800, Glen Zorn (gwz) wrote:
>> On 2/27/2006 09:09 PM, Barney Wolff wrote:
>>> Greg Weber and I have written a draft defining an Extended-Space
>>> attribute.  Here's the abstract:
>>>=20
>>>    The RADIUS protocol is being extended beyond the wildest
>>>    imaginations of its original designers.
>>=20
>> Unless we worked at Livingston, I don't think we are the original
>> designers so how do we know what their wildest imaginations were?=20
>> OTOH, the kind of extensions happening now were certainly within the
>> wildest (or even mundane) imaginations of the RADIUS WG; their
>> pursuit was simply not allowed in that venue (thus the whole
>> NASREQ/Diameter fiasco).    =20
>=20
> I certainly don't claim to be a designer of RADIUS. =20

Nor I.

> But I did join
> the list in Feb 1995, when RADIUS was at draft -02, and exchanged
> quite a lot of cordial email with Carl Rigney, and even some with
> Bill Simpson. =20

I don't recall when I joined the list, but I did attend the BOFs...

> I have too much respect for the designers to believe
> that had imaginations back then predicted the state of things more
> than a decade later there would have been no mechanism for extending
> Type and Length, at least.=20

IIRC, it was not a lack of imagination or vision on the part of Carl or =
Bill (a visionary if ever there was one!) but structural and political =
pressures that constrained the protocol design (kind of like now).
    =20
>=20
> Regards,
> Barney

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 01 Mar 2006 05:06:08 +0000
Date: Wed, 1 Mar 2006 00:05:44 -0500
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Extended-Space attribute draft available

On Tue, Feb 28, 2006 at 07:10:35PM -0800, Glen Zorn (gwz) wrote:
> On 2/27/2006 09:09 PM, Barney Wolff wrote:
> > Greg Weber and I have written a draft defining an Extended-Space
> > attribute.  Here's the abstract:
> > 
> >    The RADIUS protocol is being extended beyond the wildest
> >    imaginations of its original designers.  
> 
> Unless we worked at Livingston, I don't think we are the original designers so how do we know what their wildest imaginations were?  OTOH, the kind of extensions happening now were certainly within the wildest (or even mundane) imaginations of the RADIUS WG; their pursuit was simply not allowed in that venue (thus the whole NASREQ/Diameter fiasco).

I certainly don't claim to be a designer of RADIUS.  But I did join
the list in Feb 1995, when RADIUS was at draft -02, and exchanged
quite a lot of cordial email with Carl Rigney, and even some with
Bill Simpson.  I have too much respect for the designers to believe
that had imaginations back then predicted the state of things more
than a decade later there would have been no mechanism for extending
Type and Length, at least.

Regards,
Barney

--
to unsubscribe send a message 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, 01 Mar 2006 04:06:20 +0000
Date: Tue, 28 Feb 2006 23:05:59 -0500
From: Barney Wolff <[email-masked]>
To: David Mitton <[email-masked]>
Cc: [email-masked]
Subject: Re: Extended-Space attribute draft available

On Tue, Feb 28, 2006 at 09:43:43PM -0500, David Mitton wrote:
> 
> An alternative to this format could be a variation on my RADIUS 
> Diameter VSA format in
> http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01.txt
> 
> where we could do something like:
> (he says, editing on the fly)....
> 
> 
> RADIUS Diameter AVP:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  Type = TBA   |    Length     |r M P r r r r r|    Segment    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Type (first segment only?)                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                      Attribute-Data ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     Flags M & P retrain their Diameter values.
> 
>       RADIUS Type = TBA
>       RADIUS Length (3~255)
>       Flags = from Diameter message
>       Segment = 0-63, Segment number for data lengths greater than 246,
>       Type = 4 bytes from the Diameter Type code
>       Data = upto 246 bytes
> 
>    For Diameter values with lengths greater than 246, the additional
>    data would be put in consecutive attributes, in the same manner as
>    EAP [RADIUS-EAP], [RFC3579].
> 
>    The Segment field will be zero for the first attribute, and each
>    sucessive attribute data segment will increment the Segment field.
>    The Vendor-Id and Vendor-Type SHALL not be repeated.
> 
>    Note that RADIUS applications that do not understand the
>    attribute will not honor the Diameter M and P flags.  These flags
>    have no meaning in RADIUS, but are preserved for vendor specific
>    meaning and potential transport back to Diameter.

Ah, the avp-header debate begins :)

The choice of the Diameter AVP header format for Extended-Space was
certainly not made on the basis of elegance or optimization of
RADIUS message size, but rather optimization of calendar time (in
the sense of hoping that it would truncate debate over details of
header format) and, secondarily, allowing a translating gateway to
simply do a bulk copy of the concatenated value fields of all the
Extended-Space attributes in the RADIUS message.

Had I been designing Diameter's data formats, I would have used ASN.1
and BER (or PER).  Is there really any device speaking either RADIUS
or Diameter that does not speak SNMP and have access to a BER library?
But it's years too late for that.

Re the header format suggested above, I'd point out that Segment is
unnecessary, as the requirement that instances of a particular RADIUS
attribute not be re-ordered provides implicit sequencing. All that's
needed is a T-flag to say Type is present.

By keeping the Diameter AVP length field, we avoided a requirement to
start each Diameter-format attribute with a new Extended-Space attribute.

Using the Diameter format accepts the proposition that increasingly
servers, and arguably clients as well, will talk both Diameter and
RADIUS, and therefore designing a third AVP header format would just
add to code complexity.

Regards,
Barney

--
to unsubscribe send a message 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, 01 Mar 2006 03:12:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Extended-Space attribute draft available
Date: Tue, 28 Feb 2006 19:10:35 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>

On 2/27/2006 09:09 PM, Barney Wolff wrote:
> Greg Weber and I have written a draft defining an Extended-Space
> attribute.  Here's the abstract:
>=20
>    The RADIUS protocol is being extended beyond the wildest
>    imaginations of its original designers. =20

Unless we worked at Livingston, I don't think we are the original =
designers so how do we know what their wildest imaginations were?  OTOH, =
the kind of extensions happening now were certainly within the wildest =
(or even mundane) imaginations of the RADIUS WG; their pursuit was =
simply not allowed in that venue (thus the whole NASREQ/Diameter =
fiasco).

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message 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, 01 Mar 2006 02:47:17 +0000
Date: Tue, 28 Feb 2006 21:43:43 -0500
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: Re: Extended-Space attribute draft available

On 2/27/2006 09:09 PM, Barney Wolff wrote:
>Greg Weber and I have written a draft defining an Extended-Space
>attribute.  Here's the abstract:
>
>    The RADIUS protocol is being extended beyond the wildest imaginations
>    of its original designers.  These extensions are pushing up against
>    the existing limitations on the numbers, length, base types and
>    grouping of RADIUS attributes.  This document specifies a method of
>    relaxing those limitations.
>
>While it works its way to the IETF draft directory, you're welcome
>to retrieve it here:
>
>http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt
>http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html
>
>This draft is a companion piece the the design guidelines draft, and,
>we hope, will be adopted as a RADEXT work item.
>
>Comments and corrections are welcome, and if necessary I can try to
>get a -01 version in before next week's deadline.
>
>Barney Wolff

An alternative to this format could be a variation on my RADIUS 
Diameter VSA format in
http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01.txt

where we could do something like:
(he says, editing on the fly)....

RADIUS Diameter AVP:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = TBA   |    Length     |r M P r r r r r|    Segment    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Type (first segment only?)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Attribute-Data ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Flags M & P retrain their Diameter values.

       RADIUS Type = TBA
       RADIUS Length (3~255)
       Flags = from Diameter message
       Segment = 0-63, Segment number for data lengths greater than 246,
       Type = 4 bytes from the Diameter Type code
       Data = upto 246 bytes

    For Diameter values with lengths greater than 246, the additional
    data would be put in consecutive attributes, in the same manner as
    EAP [RADIUS-EAP], [RFC3579].

    The Segment field will be zero for the first attribute, and each
    sucessive attribute data segment will increment the Segment field.
    The Vendor-Id and Vendor-Type SHALL not be repeated.

    Note that RADIUS applications that do not understand the
    attribute will not honor the Diameter M and P flags.  These flags
    have no meaning in RADIUS, but are preserved for vendor specific
    meaning and potential transport back to Diameter.

Dave. 

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