Subject: RE: Issue 190: Relationship of Tunnel and Egress-VLAN attributes
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 30 Apr 2006 16:14:35 -0700

How about this for Section 2.3?

"The tunnel attributes described in [RFC3580] and the Egress-VLAN-Name
attribute both can be used to configure the egress VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS packet.  When they do appear concurrently,
the list of allowed VLANs is the concatenation of the
Egress-VLAN-Name and the Tunnel-Private-Group-ID (81)
attributes.

The Egress-VLAN-Name attribute does not alter the ingress VLAN for untagged 
traffic
on a port (also known as the PVID).  The tunnel attributes from
[RFC3580] should be relied upon instead to set the PVID."

>From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
>To: "Bernard Aboba" <[email-masked]>,<[email-masked]>
>Subject: Issue 190: Relationship of Tunnel and Egress-VLAN attributes
>Date: Sun, 30 Apr 2006 11:12:36 -0700
>
>
>Bernard,
>
>I'm satisfied with the modification made to section 2.1.  However, I
>also asked that a similar statement be added to section 2.3.  This would
>remove any possibility of ambiguity.
>
>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: Sun, 30 Apr 2006 18:12:47 +0000
Content-class: urn:content-classes:message
Subject: Issue 190: Relationship of Tunnel and Egress-VLAN attributes
Date: Sun, 30 Apr 2006 11:12:36 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard,

I'm satisfied with the modification made to section 2.1.  However, I
also asked that a similar statement be added to section 2.3.  This would
remove any possibility of ambiguity.

MS =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, April 29, 2006 7:42 AM
> To: [email-masked]
> Subject: Conclusion of WG last call on VLAN/Priority Document
>=20
> RADEXT WG last call has concluded on the VLAN/Priority=20
> document, draft-ietf-radext-vlan-03.txt.
>=20
> Three issues were raised: 189, 190, 191.  The issues and=20
> their resolutions are availalble here:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> Based on the resolutions, an -04 document has been submitted,=20
> and the IESG has been requested to start IETF last call, as=20
> part of considering the document for publication as a=20
> Proposed Standard.
>=20
> Until the -04 draft shows up on the archive, it is available here:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-04.txt
>=20
> Any issues submitted after this point will be handled as part=20
> of IETF last call.
>=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: Sun, 30 Apr 2006 17:43:12 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes
Date: Sun, 30 Apr 2006 10:42:26 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Congdon, Paul T (ProCurve)" <[email-masked]>, <[email-masked]>

Ok with me.

MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, April 28, 2006 4:39 PM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Subject: RE: FW: Vlan draft - relationhip of tunnel=20
> attributes and egress-xxx attributes
>=20
> How about this (insert in Section 2.1, second paragraph):
>=20
> "As defined in [RFC3580], the VLAN assigned via tunnel=20
> attributes applies both to the ingress VLANID for untagged=20
> packets (known as the PVID) and the egress VLANID for=20
> untagged packets.
> In contrast, the Egress-VLANID attribute configures only the=20
> egress VLANID for either tagged or untagged packets. The=20
> Egress-VLANID attribute MAY be included in the same RADIUS=20
> packet as [RFC3580] tunnel attributes; however, the=20
> Egress-VLANID attribute is not necessary if it is being used=20
> to configure the same untagged VLANID included in tunnel attributes.
> To configure an untagged VLAN for both ingress and egress,=20
> the tunnel attrubutes of [RFC3580] MUST be used."
>=20
>=20
>=20
> >From: "Congdon, Paul T (ProCurve)" <[email-masked]>
> >To: <[email-masked]>
> >Subject: FW: Vlan draft -  relationhip of tunnel attributes and=20
> >egress-xxx attributes
> >Date: Thu, 27 Apr 2006 21:12:57 -0700
> >
> >
> >some how the list got dropped... Comments welcome.
> >
> >
> >________________________________
> >
> >From: Congdon, Paul T (ProCurve)
> >Sent: Thursday, April 27, 2006 8:05 PM
> >To: Sanchez, Mauricio (ProCurve)
> >Subject: RE: Vlan draft - relationhip of tunnel attributes and=20
> >egress-xxx attributes
> >
> >
> >Ooops... Here are the suggested changes I was going to make.   Word
> >smithing expected... Replace the two paragraphs suggested with the=20
> >following.
> >
> >"The tunnel attributes used for VLAN assignment described in=20
> [RFC3580]=20
> >configure both the ingress VLAN ID for untagged packets,=20
> also know as=20
> >the PVID, and the egress VLAN ID for untagged packets on=20
> that same VLAN.
> >The Egress-VLANID configures only the egress VLAN ID for=20
> either tagged=20
> >or untagged packets.  It is not necessary to use the Egress-VLANID=20
> >attribute to configure the same untagged VLANID that the tunnel=20
> >attributes of [RFC3580] confiures.  These attributes can be used=20
> >concurrently and MAY appear in the same RADIUS message.  To=20
> configure=20
> >an untagged VLAN for both ingress and egress the tunnel=20
> attrubutes of=20
> >[RFC3580] MUST be used."
> >
> >Paul
> >
> >
> >________________________________
> >
> >	From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
> >(ProCurve)
> >	Sent: Thursday, April 27, 2006 5:44 PM
> >	To: [email-masked]
> >	Subject: Vlan draft - relationhip of tunnel attributes=20
> and egress-xxx=20
> >attributes
> >
> >
> >
> >	Relationship of tunnel attributes and egress-xxx attributes
> >	address: [email-masked] Date first submitted: 4/27/06
> >	Reference: none
> >	Document: draft-ietf-radext-vlan-04.txt
> >	Comment type: T
> >	Priority: S
> >	Section: 2.1, 2.3
> >	Rationale/Explanation of issue:
> >	While the introduction acknowledges tunnel attributes from
> >rfc2868 and rfc3580, there is no guidance on their use with the=20
> >egress-vlanid and egress-vlan-name attributes.  I suggest=20
> formalizing=20
> >the fact that they can be used concurrently and providing=20
> guidance on=20
> >their interaction/relationship.
> >
> >	Requested change:
> >
> >	1) To section 2.1 add the following paragraph between=20
> the second and=20
> >third paragraphs of the description section for egress-vlanid:
> >
> >	"Tunnel attributes, as described in [RFC2868] and=20
> [RFC3580], and=20
> >Egress-VLANID both can be used to configure the egress  VLAN for=20
> >untagged packets.  These attributes can be used concurrently and MAY=20
> >appear in the same RADIUS message.  When they do appear=20
> concurrently,=20
> >the list of allowed VLANs consists of the concatenation of all=20
> >Egress-VLANID attributes and the Tunnel-Private-Group-ID(81)=20
> attribute.
> >
> >	Egress-VLANID does not alter the ingress VLAN untagged=20
> traffic on a=20
> >port, also known as the PVID.  The tunnel attributes from=20
> [RFC2868] and=20
> >[RFC3580] should be relied upon instead to set the PVID."
> >
> >
> >	2) To section 2.3 add the following paragraph between=20
> the first and=20
> >second paragraphs of the description section for egress-vlan-name:
> >
> >	"Tunnel attributes, as described in [RFC2868] and=20
> [RFC3580], and=20
> >Egress-VLAN-Name both can be used to configure the egress VLAN for=20
> >untagged packets.  These attributes can be used concurrently and MAY=20
> >appear in the same RADIUS message.  When they do appear=20
> concurrently,=20
> >the list of allowed VLANs consists of the concatenation of all=20
> >Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)=20
> >attribute.
> >
> >	Egress-VLAN-Name does not alter the ingress VLAN for=20
> untagged traffic=20
> >on a port, also known as the PVID.  The tunnel attributes from=20
> >[RFC2868] and [RFC3580] should be relied upon instead to set=20
> the PVID."
> >
> >
> >	--------------------------------------------
> >	Mauricio Sanchez, CISSP
> >	Network Security Architect
> >	ProCurve Networking Business
> >	Hewlett Packard
> >	8000 Foothills Boulevard, ms 5557
> >	Roseville CA, 95747-5557
> >
> >	916.785.1910 Tel
> >	916.785.1815 Fax
> >	[email-masked]
> >	--------------------------------------------
> >
>=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: Sat, 29 Apr 2006 14:42:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Conclusion of WG last call on VLAN/Priority Document
Date: Sat, 29 Apr 2006 07:41:45 -0700

RADEXT WG last call has concluded on the VLAN/Priority document, 
draft-ietf-radext-vlan-03.txt.

Three issues were raised: 189, 190, 191.  The issues and their resolutions 
are availalble here:
http://www.drizzle.com/~aboba/RADEXT/

Based on the resolutions, an -04 document has been submitted, and the IESG 
has been requested to start IETF last call, as part of considering the 
document for publication as a Proposed Standard.

Until the -04 draft shows up on the archive, it is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-04.txt

Any issues submitted after this point will be handled as part of IETF last 
call.

--
to unsubscribe send a message 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, 29 Apr 2006 06:02:47 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes
Date: Fri, 28 Apr 2006 23:02:12 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This sounds good to me=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Friday, April 28, 2006 4:39 PM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Subject: RE: FW: Vlan draft - relationhip of tunnel=20
> attributes and egress-xxx attributes
>=20
> How about this (insert in Section 2.1, second paragraph):
>=20
> "As defined in [RFC3580], the VLAN assigned via tunnel=20
> attributes applies both to the ingress VLANID for untagged=20
> packets (known as the PVID) and the egress VLANID for=20
> untagged packets.
> In contrast, the Egress-VLANID attribute configures only the=20
> egress VLANID for either tagged or untagged packets. The=20
> Egress-VLANID attribute MAY be included in the same RADIUS=20
> packet as [RFC3580] tunnel attributes; however, the=20
> Egress-VLANID attribute is not necessary if it is being used=20
> to configure the same untagged VLANID included in tunnel attributes.
> To configure an untagged VLAN for both ingress and egress,=20
> the tunnel attrubutes of [RFC3580] MUST be used."
>=20
>=20
>=20
> >From: "Congdon, Paul T (ProCurve)" <[email-masked]>
> >To: <[email-masked]>
> >Subject: FW: Vlan draft -  relationhip of tunnel attributes and=20
> >egress-xxx attributes
> >Date: Thu, 27 Apr 2006 21:12:57 -0700
> >
> >
> >some how the list got dropped... Comments welcome.
> >
> >
> >________________________________
> >
> >From: Congdon, Paul T (ProCurve)
> >Sent: Thursday, April 27, 2006 8:05 PM
> >To: Sanchez, Mauricio (ProCurve)
> >Subject: RE: Vlan draft - relationhip of tunnel attributes and=20
> >egress-xxx attributes
> >
> >
> >Ooops... Here are the suggested changes I was going to make.   Word
> >smithing expected... Replace the two paragraphs suggested with the=20
> >following.
> >
> >"The tunnel attributes used for VLAN assignment described in=20
> [RFC3580]=20
> >configure both the ingress VLAN ID for untagged packets,=20
> also know as=20
> >the PVID, and the egress VLAN ID for untagged packets on=20
> that same VLAN.
> >The Egress-VLANID configures only the egress VLAN ID for=20
> either tagged=20
> >or untagged packets.  It is not necessary to use the Egress-VLANID=20
> >attribute to configure the same untagged VLANID that the tunnel=20
> >attributes of [RFC3580] confiures.  These attributes can be used=20
> >concurrently and MAY appear in the same RADIUS message.  To=20
> configure=20
> >an untagged VLAN for both ingress and egress the tunnel=20
> attrubutes of=20
> >[RFC3580] MUST be used."
> >
> >Paul
> >
> >
> >________________________________
> >
> >	From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
> >(ProCurve)
> >	Sent: Thursday, April 27, 2006 5:44 PM
> >	To: [email-masked]
> >	Subject: Vlan draft - relationhip of tunnel attributes=20
> and egress-xxx=20
> >attributes
> >
> >
> >
> >	Relationship of tunnel attributes and egress-xxx attributes
> >	address: [email-masked] Date first submitted: 4/27/06
> >	Reference: none
> >	Document: draft-ietf-radext-vlan-04.txt
> >	Comment type: T
> >	Priority: S
> >	Section: 2.1, 2.3
> >	Rationale/Explanation of issue:
> >	While the introduction acknowledges tunnel attributes from
> >rfc2868 and rfc3580, there is no guidance on their use with the=20
> >egress-vlanid and egress-vlan-name attributes.  I suggest=20
> formalizing=20
> >the fact that they can be used concurrently and providing=20
> guidance on=20
> >their interaction/relationship.
> >
> >	Requested change:
> >
> >	1) To section 2.1 add the following paragraph between=20
> the second and=20
> >third paragraphs of the description section for egress-vlanid:
> >
> >	"Tunnel attributes, as described in [RFC2868] and=20
> [RFC3580], and=20
> >Egress-VLANID both can be used to configure the egress  VLAN for=20
> >untagged packets.  These attributes can be used concurrently and MAY=20
> >appear in the same RADIUS message.  When they do appear=20
> concurrently,=20
> >the list of allowed VLANs consists of the concatenation of all=20
> >Egress-VLANID attributes and the Tunnel-Private-Group-ID(81)=20
> attribute.
> >
> >	Egress-VLANID does not alter the ingress VLAN untagged=20
> traffic on a=20
> >port, also known as the PVID.  The tunnel attributes from=20
> [RFC2868] and=20
> >[RFC3580] should be relied upon instead to set the PVID."
> >
> >
> >	2) To section 2.3 add the following paragraph between=20
> the first and=20
> >second paragraphs of the description section for egress-vlan-name:
> >
> >	"Tunnel attributes, as described in [RFC2868] and=20
> [RFC3580], and=20
> >Egress-VLAN-Name both can be used to configure the egress VLAN for=20
> >untagged packets.  These attributes can be used concurrently and MAY=20
> >appear in the same RADIUS message.  When they do appear=20
> concurrently,=20
> >the list of allowed VLANs consists of the concatenation of all=20
> >Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)=20
> >attribute.
> >
> >	Egress-VLAN-Name does not alter the ingress VLAN for=20
> untagged traffic=20
> >on a port, also known as the PVID.  The tunnel attributes from=20
> >[RFC2868] and [RFC3580] should be relied upon instead to set=20
> the PVID."
> >
> >
> >	--------------------------------------------
> >	Mauricio Sanchez, CISSP
> >	Network Security Architect
> >	ProCurve Networking Business
> >	Hewlett Packard
> >	8000 Foothills Boulevard, ms 5557
> >	Roseville CA, 95747-5557
> >
> >	916.785.1910 Tel
> >	916.785.1815 Fax
> >	[email-masked]
> >	--------------------------------------------
> >
>=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/>

Delivery-date: Fri, 28 Apr 2006 23:39:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes
Date: Fri, 28 Apr 2006 16:38:42 -0700

How about this (insert in Section 2.1, second paragraph):

"As defined in [RFC3580], the VLAN assigned via tunnel attributes applies 
both to the ingress VLANID for untagged packets (known as the PVID) and the 
egress VLANID for untagged packets.
In contrast, the Egress-VLANID attribute configures only the egress VLANID 
for either tagged or untagged packets. The Egress-VLANID attribute MAY be 
included in the same RADIUS packet as [RFC3580] tunnel attributes; however, 
the Egress-VLANID attribute is not necessary if it is being used to 
configure the same untagged VLANID included in tunnel attributes.
To configure an untagged VLAN for both ingress and egress, the tunnel 
attrubutes of [RFC3580] MUST be used."

>From: "Congdon, Paul T (ProCurve)" <[email-masked]>
>To: <[email-masked]>
>Subject: FW: Vlan draft -  relationhip of tunnel attributes and egress-xxx 
>attributes
>Date: Thu, 27 Apr 2006 21:12:57 -0700
>
>
>some how the list got dropped... Comments welcome.
>
>
>________________________________
>
>From: Congdon, Paul T (ProCurve)
>Sent: Thursday, April 27, 2006 8:05 PM
>To: Sanchez, Mauricio (ProCurve)
>Subject: RE: Vlan draft - relationhip of tunnel attributes and
>egress-xxx attributes
>
>
>Ooops... Here are the suggested changes I was going to make.   Word
>smithing expected... Replace the two paragraphs suggested with the
>following.
>
>"The tunnel attributes used for VLAN assignment described in [RFC3580]
>configure both the ingress VLAN ID for untagged packets, also know as
>the PVID, and the egress VLAN ID for untagged packets on that same VLAN.
>The Egress-VLANID configures only the egress VLAN ID for either tagged
>or untagged packets.  It is not necessary to use the Egress-VLANID
>attribute to configure the same untagged VLANID that the tunnel
>attributes of [RFC3580] confiures.  These attributes can be used
>concurrently and MAY appear in the same RADIUS message.  To configure an
>untagged VLAN for both ingress and egress the tunnel attrubutes of
>[RFC3580] MUST be used."
>
>Paul
>
>
>________________________________
>
>	From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
>(ProCurve)
>	Sent: Thursday, April 27, 2006 5:44 PM
>	To: [email-masked]
>	Subject: Vlan draft - relationhip of tunnel attributes and
>egress-xxx attributes
>
>
>
>	Relationship of tunnel attributes and egress-xxx attributes
>	address: [email-masked] Date first submitted: 4/27/06
>	Reference: none
>	Document: draft-ietf-radext-vlan-04.txt
>	Comment type: T
>	Priority: S
>	Section: 2.1, 2.3
>	Rationale/Explanation of issue:
>	While the introduction acknowledges tunnel attributes from
>rfc2868 and rfc3580, there is no guidance on their use with the
>egress-vlanid and egress-vlan-name attributes.  I suggest formalizing
>the fact that they can be used concurrently and providing guidance on
>their interaction/relationship.
>
>	Requested change:
>
>	1) To section 2.1 add the following paragraph between the second
>and third paragraphs of the description section for egress-vlanid:
>
>	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
>Egress-VLANID both can be used to configure the egress  VLAN for
>untagged packets.  These attributes can be used concurrently and MAY
>appear in the same RADIUS message.  When they do appear concurrently,
>the list of allowed VLANs consists of the concatenation of all
>Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) attribute.
>
>	Egress-VLANID does not alter the ingress VLAN untagged traffic
>on a port, also known as the PVID.  The tunnel attributes from [RFC2868]
>and [RFC3580] should be relied upon instead to set the PVID."
>
>
>	2) To section 2.3 add the following paragraph between the first
>and second paragraphs of the description section for egress-vlan-name:
>
>	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
>Egress-VLAN-Name both can be used to configure the egress VLAN for
>untagged packets.  These attributes can be used concurrently and MAY
>appear in the same RADIUS message.  When they do appear concurrently,
>the list of allowed VLANs consists of the concatenation of all
>Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)
>attribute.
>
>	Egress-VLAN-Name does not alter the ingress VLAN for untagged
>traffic on a port, also known as the PVID.  The tunnel attributes from
>[RFC2868] and [RFC3580] should be relied upon instead to set the PVID."
>
>
>	--------------------------------------------
>	Mauricio Sanchez, CISSP
>	Network Security Architect
>	ProCurve Networking Business
>	Hewlett Packard
>	8000 Foothills Boulevard, ms 5557
>	Roseville CA, 95747-5557
>
>	916.785.1910 Tel
>	916.785.1815 Fax
>	[email-masked]
>	--------------------------------------------
>

--
to unsubscribe send a message 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, 28 Apr 2006 21:22:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Vlan draft -  relationhip of tunnel attributes and egress-xxx attributes
Date: Fri, 28 Apr 2006 14:20:50 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Cc: <[email-masked]>

The first sentence is a little long and could probably be split at the
'whereas' part, but otherwise this sounds good to me.=20

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve)=20
> Sent: Friday, April 28, 2006 9:51 AM
> To: Congdon, Paul T (ProCurve)
> Cc: [email-masked]
> Subject: RE: Vlan draft - relationhip of tunnel attributes=20
> and egress-xxx attributes
>=20
> Paul
>=20
> How about the following?  Your text has some missing=20
> 'ingress' denotes.=20
> =20
> "The tunnel attributes used for VLAN assignment, as described=20
> in [RFC3580], concurrently configure both the untagged=20
> ingress VLAN, also known as the PVID, and the untagged egress=20
> VLAN, whereas Egress-VLANID can only configure the egress=20
> VLAN ID for untagged or tagged frames. Tunnel attributes and=20
> Egress-VLANID can be used at the same time and MAY appear in=20
> the same RADIUS message. When using both concurrently, an=20
> Egress-VLANID attribute is unnecessary to set the same=20
> untagged egress VLAN set by the tunnel attributes. However,=20
> to configure an untagged VLAN for both ingress and egress=20
> frames, the tunnel attributes of [RFC3580] MUST be used."
>=20
> MS
> ________________________________
>=20
> 	From: Congdon, Paul T (ProCurve)=20
> 	Sent: Thursday, April 27, 2006 8:05 PM
> 	To: Sanchez, Mauricio (ProCurve)
> 	Subject: RE: Vlan draft - relationhip of tunnel=20
> attributes and egress-xxx attributes
> =09
> =09
> 	Ooops... Here are the suggested changes I was going to=20
> make.   Word smithing expected... Replace the two paragraphs=20
> suggested with the following.
> 	=20
> 	"The tunnel attributes used for VLAN assignment=20
> described in [RFC3580] configure both the ingress VLAN ID for=20
> untagged packets, also know as the PVID, and the egress VLAN=20
> ID for untagged packets on that same VLAN.   The=20
> Egress-VLANID configures only the egress VLAN ID for either=20
> tagged or untagged packets.  It is not necessary to use the=20
> Egress-VLANID attribute to configure the same untagged VLANID=20
> that the tunnel attributes of [RFC3580] confiures.  These=20
> attributes can be used concurrently and MAY appear in the=20
> same RADIUS message.  To configure an untagged VLAN for both=20
> ingress and egress the tunnel attrubutes of [RFC3580] MUST be used."
> 	=20
> 	Paul
>=20
>=20
> ________________________________
>=20
> 		From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Sanchez,=20
> Mauricio (ProCurve)
> 		Sent: Thursday, April 27, 2006 5:44 PM
> 		To: [email-masked]
> 		Subject: Vlan draft - relationhip of tunnel=20
> attributes and egress-xxx attributes
> 	=09
> 	=09
>=20
> 		Relationship of tunnel attributes and=20
> egress-xxx attributes=20
> 		address: [email-masked] Date first=20
> submitted: 4/27/06=20
> 		Reference: none=20
> 		Document: draft-ietf-radext-vlan-04.txt=20
> 		Comment type: T=20
> 		Priority: S=20
> 		Section: 2.1, 2.3=20
> 		Rationale/Explanation of issue:=20
> 		While the introduction acknowledges tunnel=20
> attributes from rfc2868 and rfc3580, there is no guidance on=20
> their use with the egress-vlanid and egress-vlan-name=20
> attributes.  I suggest formalizing the fact that they can be=20
> used concurrently and providing guidance on their=20
> interaction/relationship.
>=20
> 		Requested change:=20
>=20
> 		1) To section 2.1 add the following paragraph=20
> between the second and third paragraphs of the description=20
> section for egress-vlanid:
>=20
> 		"Tunnel attributes, as described in [RFC2868]=20
> and [RFC3580], and Egress-VLANID both can be used to=20
> configure the egress  VLAN for untagged packets.  These=20
> attributes can be used concurrently and MAY appear in the=20
> same RADIUS message.  When they do appear concurrently, the=20
> list of allowed VLANs consists of the concatenation of all=20
> Egress-VLANID attributes and the Tunnel-Private-Group-ID(81)=20
> attribute.=20
>=20
> 		Egress-VLANID does not alter the ingress VLAN=20
> untagged traffic on a port, also known as the PVID.  The=20
> tunnel attributes from [RFC2868] and [RFC3580] should be=20
> relied upon instead to set the PVID."
>=20
>=20
> 		2) To section 2.3 add the following paragraph=20
> between the first and second paragraphs of the description=20
> section for egress-vlan-name:
>=20
> 		"Tunnel attributes, as described in [RFC2868]=20
> and [RFC3580], and Egress-VLAN-Name both can be used to=20
> configure the egress VLAN for untagged packets.  These=20
> attributes can be used concurrently and MAY appear in the=20
> same RADIUS message.  When they do appear concurrently, the=20
> list of allowed VLANs consists of the concatenation of all=20
> Egress-VLAN-Name attributes and the=20
> Tunnel-Private-Group-ID(81) attribute.=20
>=20
> 		Egress-VLAN-Name does not alter the ingress=20
> VLAN for untagged traffic on a port, also known as the PVID. =20
> The tunnel attributes from [RFC2868] and [RFC3580] should be=20
> relied upon instead to set the PVID."
>=20
>=20
> 		--------------------------------------------=20
> 		Mauricio Sanchez, CISSP=20
> 		Network Security Architect=20
> 		ProCurve Networking Business=20
> 		Hewlett Packard=20
> 		8000 Foothills Boulevard, ms 5557=20
> 		Roseville CA, 95747-5557=20
>=20
> 		916.785.1910 Tel=20
> 		916.785.1815 Fax=20
> 		[email-masked]=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/>

Delivery-date: Fri, 28 Apr 2006 16:52:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Vlan draft -  relationhip of tunnel attributes and egress-xxx attributes
Date: Fri, 28 Apr 2006 09:51:23 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
Cc: <[email-masked]>

Paul

How about the following?  Your text has some missing 'ingress' denotes.=20
=20
"The tunnel attributes used for VLAN assignment, as described in
[RFC3580], concurrently configure both the untagged ingress VLAN, also
known as the PVID, and the untagged egress VLAN, whereas Egress-VLANID
can only configure the egress VLAN ID for untagged or tagged frames.
Tunnel attributes and Egress-VLANID can be used at the same time and MAY
appear in the same RADIUS message. When using both concurrently, an
Egress-VLANID attribute is unnecessary to set the same untagged egress
VLAN set by the tunnel attributes. However, to configure an untagged
VLAN for both ingress and egress frames, the tunnel attributes of
[RFC3580] MUST be used."

MS
________________________________

	From: Congdon, Paul T (ProCurve)=20
	Sent: Thursday, April 27, 2006 8:05 PM
	To: Sanchez, Mauricio (ProCurve)
	Subject: RE: Vlan draft - relationhip of tunnel attributes and
egress-xxx attributes
=09
=09
	Ooops... Here are the suggested changes I was going to make.
Word smithing expected... Replace the two paragraphs suggested with the
following.
	=20
	"The tunnel attributes used for VLAN assignment described in
[RFC3580] configure both the ingress VLAN ID for untagged packets, also
know as the PVID, and the egress VLAN ID for untagged packets on that
same VLAN.   The Egress-VLANID configures only the egress VLAN ID for
either tagged or untagged packets.  It is not necessary to use the
Egress-VLANID attribute to configure the same untagged VLANID that the
tunnel attributes of [RFC3580] confiures.  These attributes can be used
concurrently and MAY appear in the same RADIUS message.  To configure an
untagged VLAN for both ingress and egress the tunnel attrubutes of
[RFC3580] MUST be used."
	=20
	Paul

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
(ProCurve)
		Sent: Thursday, April 27, 2006 5:44 PM
		To: [email-masked]
		Subject: Vlan draft - relationhip of tunnel attributes
and egress-xxx attributes
	=09
	=09

		Relationship of tunnel attributes and egress-xxx
attributes=20
		address: [email-masked] Date first submitted:
4/27/06=20
		Reference: none=20
		Document: draft-ietf-radext-vlan-04.txt=20
		Comment type: T=20
		Priority: S=20
		Section: 2.1, 2.3=20
		Rationale/Explanation of issue:=20
		While the introduction acknowledges tunnel attributes
from rfc2868 and rfc3580, there is no guidance on their use with the
egress-vlanid and egress-vlan-name attributes.  I suggest formalizing
the fact that they can be used concurrently and providing guidance on
their interaction/relationship.

		Requested change:=20

		1) To section 2.1 add the following paragraph between
the second and third paragraphs of the description section for
egress-vlanid:

		"Tunnel attributes, as described in [RFC2868] and
[RFC3580], and Egress-VLANID both can be used to configure the egress
VLAN for untagged packets.  These attributes can be used concurrently
and MAY appear in the same RADIUS message.  When they do appear
concurrently, the list of allowed VLANs consists of the concatenation of
all Egress-VLANID attributes and the Tunnel-Private-Group-ID(81)
attribute.=20

		Egress-VLANID does not alter the ingress VLAN untagged
traffic on a port, also known as the PVID.  The tunnel attributes from
[RFC2868] and [RFC3580] should be relied upon instead to set the PVID."

		2) To section 2.3 add the following paragraph between
the first and second paragraphs of the description section for
egress-vlan-name:

		"Tunnel attributes, as described in [RFC2868] and
[RFC3580], and Egress-VLAN-Name both can be used to configure the egress
VLAN for untagged packets.  These attributes can be used concurrently
and MAY appear in the same RADIUS message.  When they do appear
concurrently, the list of allowed VLANs consists of the concatenation of
all Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)
attribute.=20

		Egress-VLAN-Name does not alter the ingress VLAN for
untagged traffic on a port, also known as the PVID.  The tunnel
attributes from [RFC2868] and [RFC3580] should be relied upon instead to
set the PVID."

		--------------------------------------------=20
		Mauricio Sanchez, CISSP=20
		Network Security Architect=20
		ProCurve Networking Business=20
		Hewlett Packard=20
		8000 Foothills Boulevard, ms 5557=20
		Roseville CA, 95747-5557=20

		916.785.1910 Tel=20
		916.785.1815 Fax=20
		[email-masked]=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: Fri, 28 Apr 2006 04:13:27 +0000
Content-class: urn:content-classes:message
Subject: FW: Vlan draft -  relationhip of tunnel attributes and egress-xxx attributes
Date: Thu, 27 Apr 2006 21:12:57 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C66A7A.07F6ED2A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
some how the list got dropped... Comments welcome.

=20
________________________________

From: Congdon, Paul T (ProCurve)=20
Sent: Thursday, April 27, 2006 8:05 PM
To: Sanchez, Mauricio (ProCurve)
Subject: RE: Vlan draft - relationhip of tunnel attributes and
egress-xxx attributes

Ooops... Here are the suggested changes I was going to make.   Word
smithing expected... Replace the two paragraphs suggested with the
following.
=20
"The tunnel attributes used for VLAN assignment described in [RFC3580]
configure both the ingress VLAN ID for untagged packets, also know as
the PVID, and the egress VLAN ID for untagged packets on that same VLAN.
The Egress-VLANID configures only the egress VLAN ID for either tagged
or untagged packets.  It is not necessary to use the Egress-VLANID
attribute to configure the same untagged VLANID that the tunnel
attributes of [RFC3580] confiures.  These attributes can be used
concurrently and MAY appear in the same RADIUS message.  To configure an
untagged VLAN for both ingress and egress the tunnel attrubutes of
[RFC3580] MUST be used."
=20
Paul

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
(ProCurve)
	Sent: Thursday, April 27, 2006 5:44 PM
	To: [email-masked]
	Subject: Vlan draft - relationhip of tunnel attributes and
egress-xxx attributes
=09
=09

	Relationship of tunnel attributes and egress-xxx attributes=20
	address: [email-masked] Date first submitted: 4/27/06=20
	Reference: none=20
	Document: draft-ietf-radext-vlan-04.txt=20
	Comment type: T=20
	Priority: S=20
	Section: 2.1, 2.3=20
	Rationale/Explanation of issue:=20
	While the introduction acknowledges tunnel attributes from
rfc2868 and rfc3580, there is no guidance on their use with the
egress-vlanid and egress-vlan-name attributes.  I suggest formalizing
the fact that they can be used concurrently and providing guidance on
their interaction/relationship.

	Requested change:=20

	1) To section 2.1 add the following paragraph between the second
and third paragraphs of the description section for egress-vlanid:

	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLANID both can be used to configure the egress  VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) attribute.=20

	Egress-VLANID does not alter the ingress VLAN untagged traffic
on a port, also known as the PVID.  The tunnel attributes from [RFC2868]
and [RFC3580] should be relied upon instead to set the PVID."

	2) To section 2.3 add the following paragraph between the first
and second paragraphs of the description section for egress-vlan-name:

	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLAN-Name both can be used to configure the egress VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)
attribute.=20

	Egress-VLAN-Name does not alter the ingress VLAN for untagged
traffic on a port, also known as the PVID.  The tunnel attributes from
[RFC2868] and [RFC3580] should be relied upon instead to set the PVID."

	--------------------------------------------=20
	Mauricio Sanchez, CISSP=20
	Network Security Architect=20
	ProCurve Networking Business=20
	Hewlett Packard=20
	8000 Foothills Boulevard, ms 5557=20
	Roseville CA, 95747-5557=20

	916.785.1910 Tel=20
	916.785.1815 Fax=20
	[email-masked]=20
	--------------------------------------------  =20

------_=_NextPart_001_01C66A7A.07F6ED2A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Vlan draft - relationhip of tunnel attributes and =
egress-xxx attributes</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D233331204-28042006></SPAN><FONT face=3DArial><FONT=20
color=3D#0000ff><FONT=20
size=3D2>some&nbsp;how&nbsp;the&nbsp;list&nbsp;got&nbsp;dropped...&nbsp;C=
omments&nbsp;welcome.</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D233331204-28042006></SPAN></FONT></FONT></FONT><BR>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Congdon, Paul T (ProCurve)=20
<BR><B>Sent:</B> Thursday, April 27, 2006 8:05 PM<BR><B>To:</B> Sanchez, =

Mauricio (ProCurve)<BR><B>Subject:</B> RE: Vlan draft - relationhip of =
tunnel=20
attributes and egress-xxx attributes<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D000315502-28042006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Ooops... Here are the suggested changes I was =
going to=20
make.&nbsp;&nbsp; Word smithing expected...&nbsp;Replace the two =
paragraphs=20
suggested with the following.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D000315502-28042006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D000315502-28042006><FONT =
face=3D"Courier New"=20
size=3D2>"The tunnel attributes used for VLAN assignment&nbsp;described =
in=20
[RFC3580] configure both the ingress VLAN ID for untagged packets, also =
know as=20
the PVID, and the egress VLAN ID for untagged packets on that same=20
VLAN.&nbsp;&nbsp; The&nbsp;Egress-VLANID&nbsp;configures only the=20
egress&nbsp;VLAN ID&nbsp;for either tagged or untagged packets.&nbsp; It =
is not=20
necessary to use the Egress-VLANID attribute to configure the same =
untagged=20
VLANID that the tunnel attributes of [RFC3580] confiures.&nbsp; These=20
attributes&nbsp;can be used concurrently and MAY appear in the same =
RADIUS=20
message.&nbsp; To configure an untagged VLAN for both ingress and egress =
the=20
tunnel attrubutes of [RFC3580] MUST be used."</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D000315502-28042006><FONT =
face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D000315502-28042006><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2>Paul</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Sanchez, =
Mauricio=20
  (ProCurve)<BR><B>Sent:</B> Thursday, April 27, 2006 5:44 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Vlan draft - relationhip of =
tunnel=20
  attributes and egress-xxx attributes<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=3D"Courier New" size=3D2>Relationship of tunnel =
attributes and=20
  egress-xxx attributes</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>address:=20
  [email-masked] Date first submitted: 4/27/06</FONT> <BR><FONT =

  face=3D"Courier New" size=3D2>Reference: none</FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>Document: draft-ietf-radext-vlan-04.txt</FONT> <BR><FONT=20
  face=3D"Courier New" size=3D2>Comment type: T</FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>Priority: S</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>Section: 2.1,=20
  2.3</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>Rationale/Explanation of=20
  issue:</FONT> <BR><FONT face=3D"Courier New" size=3D2>While the =
introduction=20
  acknowledges tunnel attributes from rfc2868 and rfc3580, there is no =
guidance=20
  on their use with the egress-vlanid and egress-vlan-name =
attributes.&nbsp; I=20
  suggest formalizing the fact that they can be used concurrently and =
providing=20
  guidance on their interaction/relationship.</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Requested change:</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>1) To section 2.1 add the =
following=20
  paragraph between the second and third paragraphs of the description =
section=20
  for egress-vlanid:</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>"Tunnel attributes, as =
described in=20
  [RFC2868] and [RFC3580], and Egress-VLANID both can be used to =
configure the=20
  egress&nbsp; VLAN for untagged packets.&nbsp; These attributes can be =
used=20
  concurrently and MAY appear in the same RADIUS message.&nbsp; When =
they do=20
  appear concurrently, the list of allowed VLANs consists of the =
concatenation=20
  of all Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) =
attribute.=20
  </FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Egress-VLANID does not alter =
the ingress=20
  VLAN untagged traffic on a port, also known as the PVID.&nbsp; The =
tunnel=20
  attributes from [RFC2868] and [RFC3580] should be relied upon instead =
to set=20
  the PVID."</FONT></P><BR>
  <P><FONT face=3D"Courier New" size=3D2>2) To section 2.3 add the =
following=20
  paragraph between the first and second paragraphs of the description =
section=20
  for egress-vlan-name:</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>"Tunnel attributes, as =
described in=20
  [RFC2868] and [RFC3580], and Egress-VLAN-Name both can be used to =
configure=20
  the egress VLAN for untagged packets.&nbsp; These attributes can be =
used=20
  concurrently and MAY appear in the same RADIUS message.&nbsp; When =
they do=20
  appear concurrently, the list of allowed VLANs consists of the =
concatenation=20
  of all Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81) =

  attribute. </FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Egress-VLAN-Name does not alter =
the ingress=20
  VLAN for untagged traffic on a port, also known as the PVID.&nbsp; The =
tunnel=20
  attributes from [RFC2868] and [RFC3580] should be relied upon instead =
to set=20
  the PVID."</FONT></P><BR>
  <P><FONT face=3DArial =
size=3D2>--------------------------------------------</FONT>=20
  <BR><FONT face=3DArial size=3D2>Mauricio Sanchez</FONT><FONT =
face=3DArial size=3D2>,=20
  CISSP</FONT> <BR><FONT face=3DArial size=3D2>Network Security =
Architect</FONT>=20
  <BR><FONT face=3DArial size=3D2>Pro</FONT><FONT face=3DArial =
size=3D2>C</FONT><FONT=20
  face=3DArial size=3D2>urve Networking Business</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Hewlett Packard</FONT> <BR><FONT face=3DArial size=3D2>8000 =
Foothills=20
  Boulevard, ms 555</FONT><FONT face=3DArial size=3D2>7</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Roseville CA, 95747-5557</FONT> </P>
  <P><FONT face=3DArial size=3D2>916.785.1910 Tel</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>916.785.1815 Fax</FONT> <BR><FONT face=3DArial=20
  size=3D2>[email-masked]</FONT> <BR><FONT face=3DArial=20
  size=3D2>--------------------------------------------&nbsp;&nbsp;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C66A7A.07F6ED2A--

--
to unsubscribe send a message 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, 28 Apr 2006 02:55:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Vlan draft -  relationhip of tunnel attributes and egress-xxx attributes
Date: Thu, 27 Apr 2006 19:55:07 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C66A6F.299E7178
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This sounds like the spirit.  I'd suggest the following changes.
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sanchez, Mauricio
(ProCurve)
	Sent: Thursday, April 27, 2006 5:44 PM
	To: [email-masked]
	Subject: Vlan draft - relationhip of tunnel attributes and
egress-xxx attributes
=09
=09

	Relationship of tunnel attributes and egress-xxx attributes=20
	address: [email-masked] Date first submitted: 4/27/06=20
	Reference: none=20
	Document: draft-ietf-radext-vlan-04.txt=20
	Comment type: T=20
	Priority: S=20
	Section: 2.1, 2.3=20
	Rationale/Explanation of issue:=20
	While the introduction acknowledges tunnel attributes from
rfc2868 and rfc3580, there is no guidance on their use with the
egress-vlanid and egress-vlan-name attributes.  I suggest formalizing
the fact that they can be used concurrently and providing guidance on
their interaction/relationship.

	Requested change:=20

	1) To section 2.1 add the following paragraph between the second
and third paragraphs of the description section for egress-vlanid:

	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLANID both can be used to configure the egress  VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) attribute.=20

	Egress-VLANID does not alter the ingress VLAN untagged traffic
on a port, also known as the PVID.  The tunnel attributes from [RFC2868]
and [RFC3580] should be relied upon instead to set the PVID."

	2) To section 2.3 add the following paragraph between the first
and second paragraphs of the description section for egress-vlan-name:

	"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLAN-Name both can be used to configure the egress VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)
attribute.=20

	Egress-VLAN-Name does not alter the ingress VLAN for untagged
traffic on a port, also known as the PVID.  The tunnel attributes from
[RFC2868] and [RFC3580] should be relied upon instead to set the PVID."

	--------------------------------------------=20
	Mauricio Sanchez, CISSP=20
	Network Security Architect=20
	ProCurve Networking Business=20
	Hewlett Packard=20
	8000 Foothills Boulevard, ms 5557=20
	Roseville CA, 95747-5557=20

	916.785.1910 Tel=20
	916.785.1815 Fax=20
	[email-masked]=20
	--------------------------------------------  =20

------_=_NextPart_001_01C66A6F.299E7178
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Vlan draft - relationhip of tunnel attributes and =
egress-xxx attributes</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D703165402-28042006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>This sounds like the spirit.&nbsp; I'd suggest =
the=20
following changes.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D703165402-28042006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Sanchez, =
Mauricio=20
  (ProCurve)<BR><B>Sent:</B> Thursday, April 27, 2006 5:44 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Vlan draft - relationhip of =
tunnel=20
  attributes and egress-xxx attributes<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=3D"Courier New" size=3D2>Relationship of tunnel =
attributes and=20
  egress-xxx attributes</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>address:=20
  [email-masked] Date first submitted: 4/27/06</FONT> <BR><FONT =

  face=3D"Courier New" size=3D2>Reference: none</FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>Document: draft-ietf-radext-vlan-04.txt</FONT> <BR><FONT=20
  face=3D"Courier New" size=3D2>Comment type: T</FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>Priority: S</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>Section: 2.1,=20
  2.3</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>Rationale/Explanation of=20
  issue:</FONT> <BR><FONT face=3D"Courier New" size=3D2>While the =
introduction=20
  acknowledges tunnel attributes from rfc2868 and rfc3580, there is no =
guidance=20
  on their use with the egress-vlanid and egress-vlan-name =
attributes.&nbsp; I=20
  suggest formalizing the fact that they can be used concurrently and =
providing=20
  guidance on their interaction/relationship.</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Requested change:</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>1) To section 2.1 add the =
following=20
  paragraph between the second and third paragraphs of the description =
section=20
  for egress-vlanid:</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>"Tunnel attributes, as =
described in=20
  [RFC2868] and [RFC3580], and Egress-VLANID both can be used to =
configure the=20
  egress&nbsp; VLAN for untagged packets.&nbsp; These attributes can be =
used=20
  concurrently and MAY appear in the same RADIUS message.&nbsp; When =
they do=20
  appear concurrently, the list of allowed VLANs consists of the =
concatenation=20
  of all Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) =
attribute.=20
  </FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Egress-VLANID does not alter =
the ingress=20
  VLAN untagged traffic on a port, also known as the PVID.&nbsp; The =
tunnel=20
  attributes from [RFC2868] and [RFC3580] should be relied upon instead =
to set=20
  the PVID."</FONT></P><BR>
  <P><FONT face=3D"Courier New" size=3D2>2) To section 2.3 add the =
following=20
  paragraph between the first and second paragraphs of the description =
section=20
  for egress-vlan-name:</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>"Tunnel attributes, as =
described in=20
  [RFC2868] and [RFC3580], and Egress-VLAN-Name both can be used to =
configure=20
  the egress VLAN for untagged packets.&nbsp; These attributes can be =
used=20
  concurrently and MAY appear in the same RADIUS message.&nbsp; When =
they do=20
  appear concurrently, the list of allowed VLANs consists of the =
concatenation=20
  of all Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81) =

  attribute. </FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>Egress-VLAN-Name does not alter =
the ingress=20
  VLAN for untagged traffic on a port, also known as the PVID.&nbsp; The =
tunnel=20
  attributes from [RFC2868] and [RFC3580] should be relied upon instead =
to set=20
  the PVID."</FONT></P><BR>
  <P><FONT face=3DArial =
size=3D2>--------------------------------------------</FONT>=20
  <BR><FONT face=3DArial size=3D2>Mauricio Sanchez</FONT><FONT =
face=3DArial size=3D2>,=20
  CISSP</FONT> <BR><FONT face=3DArial size=3D2>Network Security =
Architect</FONT>=20
  <BR><FONT face=3DArial size=3D2>Pro</FONT><FONT face=3DArial =
size=3D2>C</FONT><FONT=20
  face=3DArial size=3D2>urve Networking Business</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Hewlett Packard</FONT> <BR><FONT face=3DArial size=3D2>8000 =
Foothills=20
  Boulevard, ms 555</FONT><FONT face=3DArial size=3D2>7</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Roseville CA, 95747-5557</FONT> </P>
  <P><FONT face=3DArial size=3D2>916.785.1910 Tel</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>916.785.1815 Fax</FONT> <BR><FONT face=3DArial=20
  size=3D2>[email-masked]</FONT> <BR><FONT face=3DArial=20
  size=3D2>--------------------------------------------&nbsp;&nbsp;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C66A6F.299E7178--

--
to unsubscribe send a message 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, 28 Apr 2006 00:44:40 +0000
Content-class: urn:content-classes:message
Subject: Vlan draft -  relationhip of tunnel attributes and egress-xxx attributes
Date: Thu, 27 Apr 2006 17:44:06 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Relationship of tunnel attributes and egress-xxx attributes
address: [email-masked] Date first submitted: 4/27/06
Reference: none
Document: draft-ietf-radext-vlan-04.txt
Comment type: T
Priority: S
Section: 2.1, 2.3
Rationale/Explanation of issue:
While the introduction acknowledges tunnel attributes from rfc2868 and
rfc3580, there is no guidance on their use with the egress-vlanid and
egress-vlan-name attributes.  I suggest formalizing the fact that they
can be used concurrently and providing guidance on their
interaction/relationship.
Requested change:

1) To section 2.1 add the following paragraph between the second and
third paragraphs of the description section for egress-vlanid:
"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLANID both can be used to configure the egress  VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) attribute.=20

Egress-VLANID does not alter the ingress VLAN untagged traffic on a
port, also known as the PVID.  The tunnel attributes from [RFC2868] and
[RFC3580] should be relied upon instead to set the PVID."

2) To section 2.3 add the following paragraph between the first and
second paragraphs of the description section for egress-vlan-name:
"Tunnel attributes, as described in [RFC2868] and [RFC3580], and
Egress-VLAN-Name both can be used to configure the egress VLAN for
untagged packets.  These attributes can be used concurrently and MAY
appear in the same RADIUS message.  When they do appear concurrently,
the list of allowed VLANs consists of the concatenation of all
Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81)
attribute.=20

Egress-VLAN-Name does not alter the ingress VLAN for untagged traffic on
a port, also known as the PVID.  The tunnel attributes from [RFC2868]
and [RFC3580] should be relied upon instead to set the PVID."

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C66A5C.DB8AC90B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.46">
<TITLE>Vlan draft -  relationhip of tunnel attributes and egress-xxx =
attributes</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Courier New">Relationship of tunnel attributes =
and egress-xxx attributes</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">address: [email-masked] =
Date first submitted: 4/27/06</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Reference: none</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Document: =
draft-ietf-radext-vlan-04.txt</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Comment type: T</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Priority: S</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Section: 2.1, 2.3</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Rationale/Explanation of =
issue:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">While the introduction =
acknowledges tunnel attributes from rfc2868 and rfc3580, there is no =
guidance on their use with the egress-vlanid and egress-vlan-name =
attributes.&nbsp; I suggest formalizing the fact that they can be used =
concurrently and providing guidance on their =
interaction/relationship.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Requested change:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">1) To section 2.1 add the =
following paragraph between the second and third paragraphs of the =
description section for egress-vlanid:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Tunnel attributes, as =
described in [RFC2868] and [RFC3580], and Egress-VLANID both can be used =
to configure the egress&nbsp; VLAN for untagged packets.&nbsp; These =
attributes can be used concurrently and MAY appear in the same RADIUS =
message.&nbsp; When they do appear concurrently, the list of allowed =
VLANs consists of the concatenation of all Egress-VLANID attributes and =
the Tunnel-Private-Group-ID(81) attribute. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Egress-VLANID does not alter the =
ingress VLAN untagged traffic on a port, also known as the PVID.&nbsp; =
The tunnel attributes from [RFC2868] and [RFC3580] should be relied upon =
instead to set the PVID.&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">2) To section 2.3 add the =
following paragraph between the first and second paragraphs of the =
description section for egress-vlan-name:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Tunnel attributes, as =
described in [RFC2868] and [RFC3580], and Egress-VLAN-Name both can be =
used to configure the egress VLAN for untagged packets.&nbsp; These =
attributes can be used concurrently and MAY appear in the same RADIUS =
message.&nbsp; When they do appear concurrently, the list of allowed =
VLANs consists of the concatenation of all Egress-VLAN-Name attributes =
and the Tunnel-Private-Group-ID(81) attribute. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Egress-VLAN-Name does not alter =
the ingress VLAN for untagged traffic on a port, also known as the =
PVID.&nbsp; The tunnel attributes from [RFC2868] and [RFC3580] should be =
relied upon instead to set the PVID.&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Pro</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">C</FONT><FONT SIZE=3D2 FACE=3D"Arial">urve Networking =
Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
555</FONT><FONT SIZE=3D2 FACE=3D"Arial">7</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C66A5C.DB8AC90B--

--
to unsubscribe send a message 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, 27 Apr 2006 19:45:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Vlan draft - Usage mxture of "packet" and "frame" terms for Ethernet frames
Date: Thu, 27 Apr 2006 12:45:17 -0700

A revised strawman incorporating fixes to the issue below is available at:

http://www.drizzle.com/~abobaRADEXT/draft-ietf-radext-vlan-04.txt

Does this address the issue?

>From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
>To: <[email-masked]>
>Subject: Vlan draft - Usage mxture of "packet" and "frame" terms for 
>Ethernet frames
>Date: Thu, 27 Apr 2006 11:45:30 -0700
>
>
>Usage mxture of "packet" and "frame" terms for Ethernet frames Submitter
>name: Mauricio Sanchez Submitter email address: [email-masked]
>Date first submitted: 4/27/06
>Reference: none
>Document: draft-ietf-radext-vlan-04.txt
>Comment type: E
>Priority: S
>Section: 2.1, 2.3
>Rationale/Explanation of issue:
>Sections 2.1 and 2.3 each begin refering to Ethernet frames as
>'packets'.  Subsequently, description changes to calling them 'frames'.
>
>Requested change:
>Change "packet" to "frame" wherever referencing Ethernet frames
>
>--------------------------------------------
>Mauricio Sanchez, CISSP
>Network Security Architect
>ProCurve Networking Business
>Hewlett Packard
>8000 Foothills Boulevard, ms 5557
>Roseville CA, 95747-5557
>
>916.785.1910 Tel
>916.785.1815 Fax
>[email-masked]
>--------------------------------------------
>

--
to unsubscribe send a message 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, 27 Apr 2006 18:46:02 +0000
Content-class: urn:content-classes:message
Subject: Vlan draft - Usage mxture of "packet" and "frame" terms for Ethernet frames
Date: Thu, 27 Apr 2006 11:45:30 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Usage mxture of "packet" and "frame" terms for Ethernet frames Submitter
name: Mauricio Sanchez Submitter email address: [email-masked]
Date first submitted: 4/27/06
Reference: none
Document: draft-ietf-radext-vlan-04.txt
Comment type: E
Priority: S
Section: 2.1, 2.3
Rationale/Explanation of issue:
Sections 2.1 and 2.3 each begin refering to Ethernet frames as
'packets'.  Subsequently, description changes to calling them 'frames'.

Requested change:
Change "packet" to "frame" wherever referencing Ethernet frames

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C66A2A.C25A4210
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.46">
<TITLE>Vlan draft - Usage mxture of &quot;packet&quot; and =
&quot;frame&quot; terms for Ethernet frames</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Usage mxture of =
&quot;packet&quot; and &quot;frame&quot; terms for Ethernet frames =
Submitter name: Mauricio Sanchez Submitter email address: =
[email-masked] Date first submitted: 4/27/06</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Reference: none</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Document: =
draft-ietf-radext-vlan-04.txt</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Comment type: E</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Priority: S</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Section: 2.1, 2.3</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Rationale/Explanation of =
issue:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Sections 2.1 and 2.3 each begin =
refering to Ethernet frames as 'packets'.&nbsp; Subsequently, =
description changes to calling them 'frames'.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Requested change:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Change &quot;packet&quot; to =
&quot;frame&quot; wherever referencing Ethernet frames</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Pro</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">C</FONT><FONT SIZE=3D2 FACE=3D"Arial">urve Networking =
Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
555</FONT><FONT SIZE=3D2 FACE=3D"Arial">7</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C66A2A.C25A4210--

--
to unsubscribe send a message 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, 26 Apr 2006 12:49:09 +0000
Content-class: urn:content-classes:message
Subject: Comments on draft-ietf-radext-filter-rules-00.txt 
Date: Wed, 26 Apr 2006 14:48:20 +0200
From: <[email-masked]>
To: <[email-masked]>

Hi,

I had a quick look at this draft. Few initial comments:

 o Introduction talks about 'home realm' and in the same
   sentence also about 'local operator'. Maybe changing
   home realm to home operator would be better?

 o Introduction also discusses VLANs. I think that text
   there does not really belong to this draft anymore.

 o terminology section lists Authenticator, Authentication
   Server and Supplicant even if those are not used in the
   text outside the terminology section. Imho a reference
   to 802.1X should be enough

 o hot-lining is also only mentioned in the terminology
   section. Should there be some more text in the draft
   itself about hot-lining e.g. in form of motivation for
   this draft? Actually I would like to see a general
   short motivation section somewhere under section 1

 o what is the purpose of the rule-delim in the
   NAS-Traffic-Rule ABNF? As far as I interpreted the
   ABNF there can be only one rule per attribute anyway?
   I could be wrong ;)

 o in the NAS-Traffic-Rule why there could not be
    - ip-proto =3D ["!"] d8
    - tcp-ports =3D ["!"] tcp-port *("," tcp-port)

   That would ease blocking of specific ports and=20
   protocols. E.g. in case of trying to block some
   virus/worm generated traffic, while allowing=20
   everything else..
=20
 o tcp-port name might be a bit misleading as ports are
   also used for other protocols. Maybe just using
   ports or similar?

 o What's the intended use for the L2 filtering? I'd
   like to see some real use case described here=20

 o section 3.1 Acct-NAS-Traffic-Rule attribute definition
    - the length should probably be >=3D 11
    - The 'String' should probably be 'Counter'
    - the description for 'Text' is missing

 o Security considerations mention VLAN-related attributes
   several times although those are now in a separate
   document.

Some nits:

 o section 2
   s/one new RADIUS authentication attributes/...attribute

Cheers,
	Jouni=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, 25 Apr 2006 05:37:17 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  RADEXT WG last call in progress on VLAN/Priority Attributes Document
Date: Mon, 24 Apr 2006 22:36:57 -0700

This is an reminder of the ongoing RADEXT WG last call on the VLAN/Priority 
document, prior to sending the document to the IESG for consideration as a 
Proposed Standard.

The document is available on the Internet Draft archive here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-03.txt

RADEXT WG last call will last until Friday April 28, 2006. Please send 
comments to the EAP WG mailing list ([email-masked]) in the format 
described on the RADEXT WG Issues List:

http://www.drizzle.com/~aboba/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, 25 Apr 2006 04:56:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Issue 189:  Attribute Semantics
Date: Mon, 24 Apr 2006 21:55:55 -0700

The text of Issue 189 is enclosed below.

The proposed resolution is to insert the following text in Section 1.3:

"The attributes described in this
document apply to a single instance of a NAS port, or more
specifically an IEEE 802.1Q bridge port. [IEEE-802.1Q] [IEEE-802.1D]
and [IEEE-802.1X] do not recognize finer management granularity than "per
port". In some cases, such as with IEEE 802.11 wireless
LANs, the concept of a "virtual port" is used in place of the
physical port. Such virtual ports are typically based on
security associations and scoped by station, or MAC address.

The attributes defined in this document are
applied on per user basis and it is expected that there is a single user
per port; however in some cases that port may be a "virtual
port".  If a NAS implementation conforming to this document
supports "virtual ports", it may be possible to provision
those "virtual ports" with unique values of the attributes
described in this document, allowing multiple users sharing
the same physical port to each have a unique set of authorization
parameters."

-------------------------------------------------------------------------
Issue 189: Attribute Semantics
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: April 18, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00468.html
Document: VLAN-03
Comment type: Technical
Priority: 1
Section: 1.3
Rationale/Explanation of issue:
An explanation of how the attributes in this document would be applied
to multi-user authentication environments, by means of "virtual ports"
is required. The base IEEE 802 documents assume per physical port
granularity. In the absence of explanation, conflicting results may
occur.

Requested change:

Add the following text:

The semantics of the RADIUS attributes described in this
document apply to a single instance of a NAS port, or more
specifically an IEEE 802.1Q bridge port. The underlying IEEE
802 standards, as listed in the references section, do not
recognize finer management granularity than "per port". In
some cases, such as with IEEE 802.11 wireless LANs, the concept
of a "virtual port" is used in place of the physical port.
Such virtual ports are typically based on security associations
and scoped by station, or MAC address.

If a NAS implementation, conforming to this document,
supports "virtual ports", it may be possible to provision
those "virtual ports" with unique values of the attributes
described in this document allowing multiple users sharing
the same physical port to each have a unique set of authorization
parameters. The authorization parameters are applied on a
per user basis and it is expected that there is a single user
per port, however in some cases that port may be a "virtual
port".

--
to unsubscribe send a message 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, 25 Apr 2006 04:53:20 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Last look at RADIUS Digest Authentication Draft
Date: Mon, 24 Apr 2006 21:52:51 -0700

This is announcement of a last look at the RADIUS Digest Authentication 
document:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-08.txt

If there are any remaining issues on this document, please send email to the 
RADEXT WG mailing list by Friday April 28, 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, 21 Apr 2006 20:30:27 +0000
Content-class: urn:content-classes:message
Subject: Minutes or the RADEXT Session at IETF-65
Date: Fri, 21 Apr 2006 16:29:39 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

(As always, please make comments on errors or omissions to the WG
mailing list.  This version has been submitted for the IETF-65
Proceedings.)

--------

IETF65 - Dallas, TX
March 21, 2006
RADIUS Extensions Working Group Minutes

Minute taker: David Mitton.  Edited by David Nelson, with input from the
Jabber Room log file.

Agenda bashing.

Milestone review -- We are trying to get to done.
The revised WG milestones, recently approved and posted to the WG's IETF
web site, were presented.  We will be managing the work flow to keep to
the new milestones.

Document Status (see slides for overview)

------
Digest Authentication: Wolfgang Beck

Wolfgang presented his recommendations for resolutions of IESG review
comments.

The one outstanding issue was the security concerns over the option for
client supplied nonces.  Sequence numbers are an option, but as
timestamps they present issues.

Glen Zorn: The size of the synchronization window is pretty large.

Dave Nelson:  There had been a request from 3GPP2 to add the option for
client supplied nonces.  Do they still need this?

David S:  We could live without it.  It's a round-trip reduction
optimization.

Bernard Aboba polled the WG members present to sense consensus:

(1) Remove the added Sequence number, and simple recommend that client
supplied nonces be used not use - several hands
(2) Keep the added Sequence number as described - nobody
(3) Remove the client supplied nonce option altogether - several hands
(3) Keep the client supplied nonce option - nobody

The consensus of the room was to remove the client supplied nonce option
altogether.  This will be confirmed on the WG mailing list.

Bernard asked for people to confirm if issues with this are closed, adn
to send that notice to the WG mailing list.

John Loughney - His issue is cleared.

------
Dynamic Authorizations MIB - Stefaan DeCnodder=20

The status of open issues was reviewed.  There seems to be consensus on
how to address the AD review comments.

The authors will submit a revised version, and a pre-submittal notice to
the WG mailing list so we can check the revisions.

------
RADIUS IPv6 MIBs - Dave Nelson

Reviewed the status of open issues from AD review, numbers 182 and 177,
item 2.  Similar in nature to the comments on the Dyn Auth MIBs.  Will
submit a revised version.

------
VLAN and Priority Attributes - Mauricio Sanchez

Split out from the IEEE 802 Attributes draft. Trying to progress the
non-contentious attributes and work on the NAS-Filter-Rule separately.
Completed WGLC last week.

Strawman revision draft posted to Bernard's web site to address WGLC
comments.  After IETF 65 and any additional comments, the revised
version will be formally submitted.

Open issue number 180, coding of attribute values:

Bernard proposes:=20
  - VLANID as an integer
  - Priority Table as a string
  - VLAN Flag? Naming and encoding questions?

It is currently 0x31 because it's easer to type an ASCII "1" as part of
name string.  It gets added to a VLAN name, but also used as a number.

VLAN Tag-Indicator is preferred as the field in by large margin of those
in the room.

NAS-Filter-Rule Attribute

Asked the DiME WG for their input, as the original version was defined
in the Diameter RFCs. The question of how to keep RADIUS and Diameter in
sync on this feature is not yet resolved.  It will require cooperation
of RADEXT with DiME.

Bernard Aboba:  3GPP has recently requested the Diameter Filter-Rule
feature in RADIUS.

Dave Nelson:  RADIUS and Diameter should not have separate dialects of
filter rules.

Bernard Aboba observed that the syntax is defined in RFC 3588, but only
used in RFC 4005.

John Loughney suggested that the NAS-Filter-Rule move to an RFC 4005
revision draft. =20

Glen Zorn:  If we're doing translations in a gateway anyway, just do
another one.  If it's just a syntax issue... (that is not answered)

Dave Nelson: The identity translation operator is always easier.

John Loughney: Agree with the proposal, but we need to write down
translation rules.

Q:  Is there a plan to continue rules for translation?

John Loughney:  This is a topic for the DiME WG, and we would like a
volunteer.

Glen Zorn: The translation rules are in RFC 3988 and RFC 4005.

--------
Delegated IPv6 Prefix - Ralph Droms

Revisions and issues because from WGLC were reviewed.

Created an attribute to match a similar one in RFC 3162.

An issue was rained with respect to attribute design guidelines.

Bernard Aboba: The issue have been resolved on the WG mailing list.

Question: What is the use case?

One use case is DOCSIS authorization.

Comment: Could also use in WiMax.

------
WLAN Attributes - Bernard Aboba

Several attributes to pass 802.11 new things
  - EAP-Key-Name
  - EAP-Peer-Name

Parviz Yegani: What is Mobility-Domain-ID for?

Bernard: Thought that IEEE 801.11r specified the need.  If you see this
advertised, then you can roam between them and get fast handoff.

Nancy Cam-Winget: Not required, but could be useful for accounting.

-------
RADIUS Design Guidelines - Greg Weber

Dave Nelson:  We have a milestone to go to WGLC in June, so we need to
get motivated on this.

Bernard Aboba: If your draft will get gated by this one, then you must
read it.

Question:  What is the level of compliance expected?

Bernard Aboba:  The content of the document is a WG issue.  If the
working group doesn't think everything needs to be enforced, then those
items should be removed from the draft.

Glen Zorn: My understanding is that the reason there is pressure to get
this out is that it is holding up other work.

Dan Romascanu: Wants the design guidelines work to move forward.  Don't
want other documents to move forward with things contrary to the
guidelines. In MIB world we have CLRs (crappy little rules), which don't
always add value.

Various commenters:  A lively discussion of when the format and
structure of complex attributes matters and when it doesn't.  The
general sense of the discussion is that it matters when some RADIUS
entity needs to pick apart and take action on individual sub-elements.

Bernard Aboba: The Wolff draft looks like Diameter VSAs.

VSEs - No, use standard attribute values instead.

Glen Zorn:   Per-attribute encryption applies only to only
User-Password.=20
Tunnel-Password is not standardized.

Greg Weber: Encrypt the whole message.

Glen Zorn: How?

Greg Weber: Use IPsec.

Glen Zorn: IPsec has problems with authentication and Trojan horse
issues.

Greg Weber: Security must be done at the application layer, because
cannot tell if IPsec is operating as desired.  Do we have an IPsec
problem in general?

Glen Zorn: I think we do.

Dave Nelson: The expectation is to produce a new standard for crypto
agility for the current mechanisms, and a guideline for accommodating
other mechanisms.

Bernard Aboba: Are we saying don't use existing RADIUS security
mechanisms?

Glen Zorn: As written, this is band-aiding the broken stuff.
=20
Bernard Aboba: Security statement or guideline?  Don't do it as we did,
but like we might say in the future.

Bert Wijnen: SDO related attribute design rules?  Do they want them?

Bernard Aboba: No, we need to give something for them to use in creating
RADIUS Extensions, without a full review here [in the IETF].  Other SDOs
try to come through the IETF or go via IANA.  Allow them to do work
independently.

Dave Nelson: Encourage SDOs to design for the standard attribute space.
Discourage them from inventing novel encapsulations, particularly when
multi-vendor interoperability is required.

Glen Zorn: Using the Vendor-Specific attribute space has kept them from
infringing on an already crowded standard attribute space.

Wolff draft on Extended RADIUS Attributes.  (See slides)

Bergen draft on Extended RADIUS Attributes.  (See slides)

Discussion of Extended RADIUS Attributes:

Question: Are we recommending Sub-Attributes?  Will these be nested or
flat?
=20
Greg Weber:  They would be hierarchical.

Parviz Yegani: Should we be following this structure?

Greg Weber: That's the issue in question.

Bernard Aboba:  Do people like it or not?  Nested is fine, but the
format is an issue.

Dave Nelson:  This is like coding standards, you love them or hate them.

Parviz Yegani:   We need to move on.  Should we redo things?

Bernard Aboba: If you don't like them, propose something better or
different.

Dave Mitton:  What is the status of these drafts?
=20
Bernard Aboba:  They are pre-WG items.

Dave Mitton: Suggest two documents, one for guidelines and one for
extended attributes.=20

------
Issues and Fixes - Bernard Aboba

Presented the current draft status.  It probably needs more input before
becoming a WG work item.

----
RADIUS-Diameter-VSAs  - Dave Mitton

Presented the status of the draft, and it relation to the Extended
Attribute ideas.

Glen Zorn:  Has an issue with putting Diameter AVPs in RADIUS messages,
becasue of the overall RADIUS message length limitation.  He is working
on a solution to the RADIUS message length constraint.

Dave Mitton: Please publish and I-D on this.

----
Pre-Paid Attributes - Parviz Yegani

Presentation of the changes from the last draft version.

Glen Zorn: Removing Authorize-Only reduces usefulness, please put it
back.

Bernard Aboba: To clarify the issue: Authorize-Only raises the
opportunity for DOS attacks, and has to be tied to State attribute to
prove prior authentication.

Glen Zorn: Issue with requiring a minimum number of positive reviews to
advance documents.

Bernard Aboba:  This recommendation came from our AD and the IESG chair.

-----
GEOPRIV RADIUS Attributes - Jouni Korhonen

Presented the changes based on RADEXT WG reviews so far.  This document
is being advanced in the GEOPRIV WG.

Bernard Aboba: We are not coming to convergence quickly enough.  We need
to figure out how to finish this.  Do we need to assign a team? =20

Dave Nelson: The major issue is with the attribute structure?

Bernard Aboba: I think there are values that will need to be picked
apart, so the current [attribute] design won't work.

Greg Weber:  This may represent another class of data blobs that need to
be picked apart, but need to be carried by multiple transports (RADIUS,
Diameter, DHCP).

Bernard Aboba: Yes, I wish I knew what DHCP was doing with location
information encoding.
=20
>From the Jabber room:  Alan DeKok: Is the format defined elsewhere?

Bernard Aboba: Yes, in the case of the civic and geospatial location
data.

Dave Nelson: How do we move forward?

Bernard Aboba: We need to get the RADIUS people to decide what they want
to do. with the help of the location people.

Dave Nelson:  The chairs will attempt to set up a small group to
facilitate this.

With this, the session time expired and the meeting adjourned.

--
to unsubscribe send a message 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, 20 Apr 2006 22:59:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Thu, 20 Apr 2006 15:58:46 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Well, the VLAN attributes in the draft are relevant to 802.1Q and the
priority regeneration table is relevant to 802.1D.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, April 19, 2006 9:42 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
>=20
> >as listed in the references section, do not
>=20
> I think we are only talking about IEEE 802.1Q, right?  IEEE=20
> 802 and IEEE 802.1D do not deal with this issue.  If it is=20
> only one or two standards, I'd prefer to refer to them explicitly.
>=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, 19 Apr 2006 19:50:40 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-digest-auth-08.txt 
Date: Wed, 19 Apr 2006 15:50:01 -0400

--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-08.txt
	Pages		: 37
	Date		: 2006-4-19
	
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-08.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-08.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-08.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-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-digest-auth-08.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, 19 Apr 2006 19:50:32 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-digest-auth-08.txt 
Date: Wed, 19 Apr 2006 15:50:01 -0400

--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-08.txt
	Pages		: 37
	Date		: 2006-4-19
	
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-08.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-08.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-08.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-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-digest-auth-08.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, 19 Apr 2006 17:09:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Wed, 19 Apr 2006 13:09:24 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> >as listed in the references section, do not
>=20
> I think we are only talking about IEEE 802.1Q, right?  IEEE 802 and
IEEE
> 802.1D do not deal with this issue.

IEEE 802.1X also.

> If it is only one or two standards, I'd
> prefer to refer to them explicitly.

Sure.  My intent was to replace the "currently", which would not fly in
an RFC, with references to specific versions of the standards.

--
to unsubscribe send a message 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, 19 Apr 2006 16:42:17 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Wed, 19 Apr 2006 09:41:56 -0700

>as listed in the references section, do not

I think we are only talking about IEEE 802.1Q, right?  IEEE 802 and IEEE 
802.1D do not deal with this issue.  If it is only one or two standards, I'd 
prefer to refer to them explicitly.

--
to unsubscribe send a message 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, 19 Apr 2006 16:15:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Wed, 19 Apr 2006 12:14:44 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

This looks OK, too.  Just rearranged a bit.  Let me add a couple of
editorial changes I had made in the version I submitted as a formal
RADEXT issue to your text, in-line, below:

> "The attributes described in this
> document apply to a single instance of a NAS port, or more
> specifically an IEEE 802.1Q bridge port.  The underlying IEEE
> 802 standards, upon which this work is based,

Remove:

> do not currently

Add:

as listed in the references section, do not

> recognize finer management granularity than "per
> port".  In some cases, such as with IEEE 802.11 wireless
> LANs, the concept of a "virtual port" is used in place of the
> physical port.  Such virtual ports are typically based on
> security associations and scoped by station, or MAC address.
>=20
> The attributes defined in this document are
> applied on per user basis and it is expected that there is a single
user
> per port; however in some cases that port may be a "virtual
> port".
>=20
> If a NAS implementation conforming to this document
> supports "virtual ports", it may be possible to provision
> those "virtual ports" with unique values of the attributes
> described in this document, allowing multiple users sharing
> the same physical port to=20

Add:

each=20

> have a unique set of authorization parameters."
>=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, 19 Apr 2006 15:54:00 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Wed, 19 Apr 2006 08:53:30 -0700

How about adding the following to the "Attribute Interpretation" section?

"The attributes described in this
document apply to a single instance of a NAS port, or more
specifically an IEEE 802.1Q bridge port.  The underlying IEEE
802 standards, upon which this work is based, do not
currently recognize finer management granularity than "per
port".  In some cases, such as with IEEE 802.11 wireless
LANs, the concept of a "virtual port" is used in place of the
physical port.  Such virtual ports are typically based on
security associations and scoped by station, or MAC address.

The attributes defined in this document are
applied on per user basis and it is expected that there is a single user
per port; however in some cases that port may be a "virtual
port".

If a NAS implementation conforming to this document
supports "virtual ports", it may be possible to provision
those "virtual ports" with unique values of the attributes
described in this document, allowing multiple users sharing
the same physical port to have a unique set of authorization
parameters."

--
to unsubscribe send a message 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, 18 Apr 2006 22:42:10 +0000
Content-class: urn:content-classes:message
Subject: New Issue: RE: RADEXT WG last call on VLAN and Priority Document
Date: Tue, 18 Apr 2006 18:41:51 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: April 18, 2006
Reference:=20
Document: VLAN & Priority Attributes
Comment type: 'T'echnical
Priority: '1' Should fix
Section: New text (maybe for Section 1.3, Attribute Interpretation)
Rationale/Explanation of issue:

An explanation of how the attributes in this document would be applied
to multi-user authentication environments, by means of "virtual ports"
is required.  The base IEEE 802 documents assume per physical port
granularity. In the absence of explanation, conflicting results may
occur.

Requested change:

Add the following text:

The semantics of the RADIUS attributes described in this
document apply to a single instance of a NAS port, or more
specifically an IEEE 802.1Q bridge port.  The underlying IEEE
802 standards, as listed in the references section, do not
recognize finer management granularity than "per port".  In=20
some cases, such as with IEEE 802.11 wireless LANs, the concept
of a "virtual port" is used in place of the physical port.=20
Such virtual ports are typically based on security associations
and scoped by station, or MAC address.

If a NAS implementation, conforming to this document,
supports "virtual ports", it may be possible to provision
those "virtual ports" with unique values of the attributes
described in this document allowing multiple users sharing
the same physical port to each have a unique set of authorization
parameters.  The authorization parameters are applied on a
per user basis and it is expected that there is a single user
per port, however in some cases that port may be a "virtual
port".

--
to unsubscribe send a message 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, 18 Apr 2006 22:22:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Tue, 18 Apr 2006 18:22:44 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Paul Congdon writes...

> Since we are talking mostly about VLANs in this draft, I suggest
> replacing 802.1D with 802.1Q below.

OK.

> The last sentence seems to drop things off sharply. In all cases, the
> assumption is one user per port.  In the case of 'virtual ports' there
> may be multiple users on the same 'physical port'.  How about the
> following modifications...
>=20
> If a NAS implementation, conforming to this document,
> supports "virtual ports", it may be possible to provision
> those "virtual ports" with unique values of the attributes
> described in this document allowing multiple users sharing
> the same physical port to have a unique set of authorization
> parameters.  The authorization parameters are applied on a
> per user basis and it is expected that there is a single user
> per port however in some cases that port may be a "virtual
> port".

That looks good to me.

Integrating your suggestions, and wordsmithing slightly, we would then
have:

<quote>

The semantics of the RADIUS attributes described in this
document apply to a single instance of a NAS port, or more
specifically an IEEE 802.1Q bridge port.  The underlying IEEE
802 standards, as listed in the references section, do not
recognize finer management granularity than "per port".  In=20
some cases, such as with IEEE 802.11 wireless LANs, the concept
of a "virtual port" is used in place of the physical port.=20
Such virtual ports are typically based on security associations
and scoped by station, or MAC address.

If a NAS implementation, conforming to this document,
supports "virtual ports", it may be possible to provision
those "virtual ports" with unique values of the attributes
described in this document allowing multiple users sharing
the same physical port to each have a unique set of authorization
parameters.  The authorization parameters are applied on a
per user basis and it is expected that there is a single user
per port, however in some cases that port may be a "virtual
port".

</quote>

How does this text look?

--
to unsubscribe send a message 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, 18 Apr 2006 22:14:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Tue, 18 Apr 2006 15:12:37 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Since we are talking mostly about VLANs in this draft, I suggest
replacing 802.1D with 802.1Q below.

The last sentence seems to drop things off sharply. In all cases, the
assumption is one user per port.  In the case of 'virtual ports' there
may be multiple users on the same 'physical port'.  How about the
following modifications...

If a NAS implementation, conforming to this document,=20
supports "virtual ports", it may be possible to provision=20
those "virtual ports" with unique values of the attributes=20
described in this document allowing multiple users sharing
the same physical port to have a unique set of authorization
parameters.  The authorization parameters are applied on a
per user basis and it is expected that there is a single user
per port however in some cases that port may be a "virtual
port".

Paul

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, April 18, 2006 9:58 AM
> To: [email-masked]
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
>=20
>=20
> Bernard Aboba writes...
>=20
> > It might be worthwhile to introduce some text to describe the
> assumptions
> > and what happens if they are violated.
>=20
> How about this:
>=20
> The semantics of the RADIUS attributes described in this=20
> document apply to a single instance of a NAS port, or more=20
> specifically an IEEE 802.1D bridge port.  The underlying IEEE=20
> 802 standards, upon which this work is based, do not=20
> currently recognize finer management granularity than "per=20
> port".  In some cases, such as with IEEE 802.11 wireless=20
> LANs, the concept of a "virtual port" is used in place of the=20
> physical port.  Such virtual ports are typically based on=20
> security associations and scoped by station, or MAC address.
>=20
> If a NAS implementation, conforming to this document,=20
> supports "virtual ports", it may be possible to provision=20
> those "virtual ports" with unique values of the attributes=20
> described in this document, on a per authenticated user=20
> basis.  If the NAS does not support a "virtual port"
> architecture, then the one user, one port, one set of=20
> authorization parameters assumption applies.
>=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: Tue, 18 Apr 2006 16:58:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Tue, 18 Apr 2006 12:58:11 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> It might be worthwhile to introduce some text to describe the
assumptions
> and what happens if they are violated.

How about this:

The semantics of the RADIUS attributes described in this document apply
to a single instance of a NAS port, or more specifically an IEEE 802.1D
bridge port.  The underlying IEEE 802 standards, upon which this work is
based, do not currently recognize finer management granularity than "per
port".  In some cases, such as with IEEE 802.11 wireless LANs, the
concept of a "virtual port" is used in place of the physical port.  Such
virtual ports are typically based on security associations and scoped by
station, or MAC address.

If a NAS implementation, conforming to this document, supports "virtual
ports", it may be possible to provision those "virtual ports" with
unique values of the attributes described in this document, on a per
authenticated user basis.  If the NAS does not support a "virtual port"
architecture, then the one user, one port, one set of authorization
parameters assumption applies.

--
to unsubscribe send a message 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, 17 Apr 2006 21:30:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 17 Apr 2006 14:29:32 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

>From a standards perspective, there are no such thing as MAC-address
based VLANs.  One could create the concept of a virtual port that is
identified by source MAC address, and then you apply the per-port
configuration to this construct.  There is some consideration of this in
802.1AE and the next version of 802.1X.

Paul=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, April 17, 2006 2:19 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
>=20
> >Given that RADIUS is sometimes used in environments in which the one=20
> >user per port rule does not hold, should we place some text in the=20
> >draft that gives guidance what to do in thee cases?  Or should we=20
> >assume that the reader of this document is sufficiently well=20
> versed in=20
> >the 802 documents that to realize that multi-user per port=20
> applications=20
> >are outside the scope of the VLAN and Priority draft?
>=20
> It might be worthwhile to introduce some text to describe the=20
> assumptions and what happens if they are violated.
>=20
> I'm also curious as to whether there was consideration of=20
> support for MAC-addressed based VLANs.  In that model=20
> (supported by recent switches) it=20
> is possible for multiple hosts to share a port.   One=20
> question that comes to=20
> mind is whether it is possible to manage such a deployment=20
> with these attributes or not.
>=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: Mon, 17 Apr 2006 21:19:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 17 Apr 2006 14:18:40 -0700

>Given that RADIUS is sometimes used in environments in which the one
>user per port rule does not hold, should we place some text in the draft
>that gives guidance what to do in thee cases?  Or should we assume that
>the reader of this document is sufficiently well versed in the 802
>documents that to realize that multi-user per port applications are
>outside the scope of the VLAN and Priority draft?

It might be worthwhile to introduce some text to describe the assumptions 
and what happens if they are violated.

I'm also curious as to whether there was consideration of support for 
MAC-addressed based VLANs.  In that model (supported by recent switches) it 
is possible for multiple hosts to share a port.   One question that comes to 
mind is whether it is possible to manage such a deployment with these 
attributes or not.

--
to unsubscribe send a message 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, 17 Apr 2006 18:03:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 17 Apr 2006 14:02:33 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...

> The User-Priority-Table attribute relates to a particular port and
since
> there is a one-to-one relationship between a port and a user it also
> relates to the user. This is the reason why this attribute is carried
in
> RADIUS in the first place.

Given that RADIUS is sometimes used in environments in which the one
user per port rule does not hold, should we place some text in the draft
that gives guidance what to do in thee cases?  Or should we assume that
the reader of this document is sufficiently well versed in the 802
documents that to realize that multi-user per port applications are
outside the scope of the VLAN and Priority draft?

--
to unsubscribe send a message 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, 16 Apr 2006 15:32:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Conclusion of RADEXT WG last call on draft-ietf-radiusext-delegated-prefix-00
Date: Sun, 16 Apr 2006 08:32:45 -0700

RADEXT WG last call has concluded on 
draft-ietf-radiusext-delegated-prefix-00.txt.  Two issues were raised, both 
editorial (185, 188).

The text of the issues is available on the RADEXT WG issues page:
http://www.drizzle.com/~aboba/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: Sun, 16 Apr 2006 15:18:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 188:  Delegated Prefix NITs
Date: Sun, 16 Apr 2006 08:17:33 -0700

Issue 188: Delegated Prefix NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 15, 2006
Reference:
Document: draft-ietf-radext-delegated-prefix-00.txt
Comment type: 'E'ditorial
Priority: S
Section: Various
Rationale/Explanation of issue:

Abstract

"
   The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is
   to be delegated to the user."

Might add a bit to the abstract, such as a reference to the RADIUS protocol. 
Suggestion:

"  This document proposes an additional RADIUS (Remote Authentication Dial
   In User Service) attribute for an IPv6 prefix that is to be delegated to 
the user.
   This attribute is usable within either RADIUS or Diameter."

Section 1

"  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."

This section does not state whether this attribute can be included in
CoA-Request, Disconnect-Request, CoA-ACK, CoA-NAK, Disconnect-ACK
Disconnect-NAK packets and Accounting-Request packets.

Section 3

The attribute table does not clarify whether the attribute can be
included in CoA-Request, Disconnect-Request, CoA-ACK, CoA-NAK,
Disconnect-ACK or Disconnect-NAK packets.

Section 5

"Use of IP SEC [7]" -> "Use of IPsec [7]"

Section 6

I don't think references [4] and [6] are normative.  I'd add an Informative 
Reference
section and move these to that section.  This way you won't have a document
at PS making normative references to Informational RFCs.

I think reference [7] has been replaced by [RFC4301].

Diameter compatibility

The document lacks a "Diameter Considerations" section.  Here is a 
suggestion
(insert prior to IANA Considerations):

4.  Diameter Considerations

   Diameter needs to define an identical attribute with the same Type
   value.  The attribute should be available as part of the NASREQ
   application [RFC4005], as well as the Diameter EAP application
   [RFC4072].

Add references to [RFC4005] and [RFC4072]:

[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
          Network Access Server Application", RFC 4005, August 2005.

[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
          Authentication Protocol (EAP) Application", RFC 4072, August
          2005.

--
to unsubscribe send a message 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, 14 Apr 2006 17:31:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue:  802.1X dependency
Date: Fri, 14 Apr 2006 10:31:28 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This looks good to me=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, April 12, 2006 10:29 AM
> To: [email-masked]
> Subject: Issue: 802.1X dependency
>=20
> Description of issue: 802.1X dependency
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: April 12th, 2006
> Reference: n/a
> Document: draft-ietf-radext-vlan-02
> Comment type: 'E'ditorial
> Priority: S
> Section: Abstract, 1, 6
> Rationale/Explanation of issue:
>=20
> The VLAN and priority attributes are usable for provisioning=20
> of access to IEEE 802 local area networks.  There is no=20
> explicit IEEE 802.1X dependency in the document.  For=20
> example, the attributes can be used with IEEE 802=20
> technologies that do not implement IEEE 802.1X, such as IEEE 802.16k.
>=20
> Therefore I do not believe that IEEE 802.1X should be listed=20
> as a normative reference.  Also, the goal should be larger=20
> than just supporting 802.1X deployments, it should be to=20
> support access to IEEE 802 local area networks.
>=20
> The proposed changes are as follows:
>=20
> Change the Appendix from:
>=20
> "   This document proposes additional RADIUS (Remote=20
> 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."
>=20
> To:
>=20
> "  This document proposes additional RADIUS (Remote=20
> Authentication Dial
>    In User Service) attributes for dynamic Virtual LAN assignment and
>    prioritization, for use in provisioning of access to IEEE 802 local
>    area networks.  These attributes are usable within either RADIUS or
>    Diameter."
>=20
> Change Section 1 from:
>=20
> "  IEEE 802.1X [IEEE-802.1X] provides "network port=20
> authentication" for
>    IEEE 802 [IEEE-802] media, including Ethernet [IEEE-802.3], Token
>    Ring and 802.11 wireless LANs [IEEE-802.11][IEEE-802.11i].
>=20
>    This document describes Virtual LAN (VLAN) and re-prioritization
>    attributes that may prove useful for provisioning of access to IEEE
>    802 local area networks with the Remote Authentication Dialin User
>    Service (RADIUS).
>=20
>    While [RFC3580] enables support for VLAN assignment based on the
>    tunnel attributes defined in [RFC2868], it does not provide support
>    for a more complete set of VLAN functionality as defined by
>    [IEEE-802.1Q].  The attributes defined in this document provide
>    support within RADIUS analogous to the management=20
> variables supported
>    in [IEEE-802.1Q] and MIB objects defined in [RFC4363].  In=20
> addition,
>    this document enables support for a wider range of [IEEE-802.1X]
>    configurations."
>=20
> To:
>=20
> "  This document describes Virtual LAN (VLAN) and re-prioritization
>    attributes that may prove useful for provisioning of access to IEEE
>    802 local area networks [IEEE-802] with the Remote Authentication
>    Dialin User Service (RADIUS).
>=20
>    While [RFC3580] enables support for VLAN assignment based on the
>    tunnel attributes defined in [RFC2868], it does not provide support
>    for a more complete set of VLAN functionality as defined by
>    [IEEE-802.1Q].  The attributes defined in this document provide
>    support within RADIUS analogous to the management=20
> variables supported
>    in [IEEE-802.1Q] and MIB objects defined in [RFC4363].  In=20
> addition,
>    this document enables support for a wider range of [IEEE-802.1X]
>    configurations."
>=20
> In Section 1.1, delete the definition of authenticator, since=20
> the word is no longer used in the document.
>=20
> Change the first paragraph of Section 6 from:
>=20
> "  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=20
> application are
>    described in [RFC3579] and [RFC3580]; security issues=20
> encountered in
>    roaming are described in [RFC2607]."
>=20
> To:
>=20
> "  This specification describes the use of RADIUS for purposes of
>    authentication, authorization and accounting in IEEE 802 local area
>    networks.  Threats and security issues for this application are
>    described in [RFC3579] and [RFC3580]; security issues=20
> encountered in
>    roaming are described in [RFC2607]."
>=20
> Move the reference to 802.1X from normative to informative. =20
> Delete references to 802.3, 802.11 and 802.11i.
>=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: Thu, 13 Apr 2006 23:08:13 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call on VLAN and Priority Document
Date: Thu, 13 Apr 2006 16:07:48 -0700

This is announcing RADEXT WG last call on the VLAN and Priority document, 
prior to sending the document on to the IESG for consideration as a Proposed 
Standard.

The -03 version of the VLAN and Priority document is available for 
inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-03.txt

We believe that this resolves all open issues filed on the RADEXT Issues 
list:
http://www.drizzle.com/~aboba/RADEXT/

Please read the document and send comments to the RADEXT WG list by Friday, 
April 28, 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: Thu, 13 Apr 2006 19:50:26 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-vlan-03.txt 
Date: Thu, 13 Apr 2006 15:50:01 -0400

--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-03.txt
	Pages		: 13
	Date		: 2006-4-13
	
This document proposes additional RADIUS (Remote Authentication Dial
   In User Service) attributes for dynamic Virtual LAN assignment and
   prioritization, for use in provisioning of access to IEEE 802 local
   area networks.  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-03.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-03.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-03.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-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-vlan-03.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, 13 Apr 2006 16:46:06 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 13 Apr 2006 09:45:41 -0700

I agree.

>For the record, I think this document is OK, based on the consensus we
>reached on the list regarding the attribute format.

--
to unsubscribe send a message 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, 13 Apr 2006 14:15:52 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Date: Thu, 13 Apr 2006 10:15:18 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

For the record, I think this document is OK, based on the consensus we
reached on the list regarding the attribute format.

--
to unsubscribe send a message 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, 12 Apr 2006 17:29:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue:  802.1X dependency
Date: Wed, 12 Apr 2006 10:28:47 -0700

Description of issue: 802.1X dependency
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 12th, 2006
Reference: n/a
Document: draft-ietf-radext-vlan-02
Comment type: 'E'ditorial
Priority: S
Section: Abstract, 1, 6
Rationale/Explanation of issue:

The VLAN and priority attributes are usable for provisioning of access to 
IEEE 802 local area networks.  There is no explicit IEEE 802.1X dependency 
in the document.  For example, the attributes can be used with IEEE 802 
technologies that do not implement IEEE 802.1X, such as IEEE 802.16k.

Therefore I do not believe that IEEE 802.1X should be listed as a normative 
reference.  Also, the goal should be larger than just supporting 802.1X 
deployments, it should be to support access to IEEE 802 local area networks.

The proposed changes are as follows:

Change the Appendix from:

"   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."

To:

"  This document proposes additional RADIUS (Remote Authentication Dial
   In User Service) attributes for dynamic Virtual LAN assignment and
   prioritization, for use in provisioning of access to IEEE 802 local
   area networks.  These attributes are usable within either RADIUS or
   Diameter."

Change Section 1 from:

"  IEEE 802.1X [IEEE-802.1X] provides "network port authentication" for
   IEEE 802 [IEEE-802] media, including Ethernet [IEEE-802.3], Token
   Ring and 802.11 wireless LANs [IEEE-802.11][IEEE-802.11i].

   This document describes Virtual LAN (VLAN) and re-prioritization
   attributes that may prove useful for provisioning of access to IEEE
   802 local area networks with the Remote Authentication Dialin User
   Service (RADIUS).

   While [RFC3580] enables support for VLAN assignment based on the
   tunnel attributes defined in [RFC2868], it does not provide support
   for a more complete set of VLAN functionality as defined by
   [IEEE-802.1Q].  The attributes defined in this document provide
   support within RADIUS analogous to the management variables supported
   in [IEEE-802.1Q] and MIB objects defined in [RFC4363].  In addition,
   this document enables support for a wider range of [IEEE-802.1X]
   configurations."

To:

"  This document describes Virtual LAN (VLAN) and re-prioritization
   attributes that may prove useful for provisioning of access to IEEE
   802 local area networks [IEEE-802] with the Remote Authentication
   Dialin User Service (RADIUS).

   While [RFC3580] enables support for VLAN assignment based on the
   tunnel attributes defined in [RFC2868], it does not provide support
   for a more complete set of VLAN functionality as defined by
   [IEEE-802.1Q].  The attributes defined in this document provide
   support within RADIUS analogous to the management variables supported
   in [IEEE-802.1Q] and MIB objects defined in [RFC4363].  In addition,
   this document enables support for a wider range of [IEEE-802.1X]
   configurations."

In Section 1.1, delete the definition of authenticator, since the word is no 
longer used in the document.

Change the first paragraph of Section 6 from:

"  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]."

To:

"  This specification describes the use of RADIUS for purposes of
   authentication, authorization and accounting in IEEE 802 local area
   networks.  Threats and security issues for this application are
   described in [RFC3579] and [RFC3580]; security issues encountered in
   roaming are described in [RFC2607]."

Move the reference to 802.1X from normative to informative.  Delete 
references to 802.3, 802.11 and 802.11i.

--
to unsubscribe send a message 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, 11 Apr 2006 13:36:33 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: AW: Use of VLAN attributes in Accounting-Requests
Date: Tue, 11 Apr 2006 06:36:07 -0700

>The VLAN parameters might be useful in Accounting-Requests since the 
>semantic is close to the >one defined in RFC 2868. I am, however, not sure 
>about the priority related attributes. What has >changed your mind 
>regarding this attribute?

As you noted, the User-Priority-Table attribute has no bearing on consumed 
resources (e.g. the packets sent/received at each priority), so I don't 
think it belongs in an Accounting-Request.

--
to unsubscribe send a message 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, 11 Apr 2006 11:48:36 +0000
Content-class: urn:content-classes:message
Subject: AW: Use of VLAN attributes in Accounting-Requests
Date: Tue, 11 Apr 2006 13:47:47 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,=20

The VLAN parameters might be useful in Accounting-Requests since the =
semantic is close to the one defined in RFC 2868. I am, however, not =
sure about the priority related attributes. What has changed your mind =
regarding this attribute?=20

Ciao
Hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Dienstag, 11. April 2006 08:35
> An: [email-masked]
> Betreff: Use of VLAN attributes in Accounting-Requests
>=20
> After reviewing RFC 2866 and 2868, it appears that existing=20
> tunneling and=20
> VLAN attributes are eligible for inclusion in=20
> Accounting-Request packets. =20
> It therefore seems that the VLAN/Priority attributes should=20
> probably also be=20
> eligible for inclusion in Accounting-Requests.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 11 Apr 2006 06:42:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: digest-auth surgery in Dallas
Date: Mon, 10 Apr 2006 23:42:46 -0700

So far, no objections have been voiced to removal of the client nonce 
generation mode in the RADIUS Digest Authentication document.  If we do not 
hear anything by Friday, April 14, we will declare WG consensus on this 
issue and remove the related text.

----------------------------------------------------------------------------------------------------------------
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, 11 Apr 2006 06:35:54 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Use of VLAN attributes in Accounting-Requests
Date: Mon, 10 Apr 2006 23:35:22 -0700

After reviewing RFC 2866 and 2868, it appears that existing tunneling and 
VLAN attributes are eligible for inclusion in Accounting-Request packets.  
It therefore seems that the VLAN/Priority attributes should probably also be 
eligible for inclusion in Accounting-Requests.

--
to unsubscribe send a message 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, 08 Apr 2006 12:49:39 +0000
Date: Sat, 08 Apr 2006 13:02:16 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Mauricio,

After the discussion I had with Bernard I thought that I understood the 
purpose and it was reasonable to me.

Here is a short summary of our discussion:

The User-Priority-Table is sent the Access-Accept and provides the 
mapping of the user priorities for each class. Semantically it provides 
something similar to DSCP remarking. The User-Priority-Table therefore 
does not need to be associated with data traffic (e.g., a particular 5 
tuple). It just maps one priority value to another one and that's fine.

The User-Priority-Table attribute relates to a particular port and since 
there is a one-to-one relationship between a port and a user it also 
relates to the user. This is the reason why this attribute is carried in 
RADIUS in the first place.

Ciao
Hannes

  Sanchez, Mauricio (ProCurve) wrote:
> I'm not sure what you're getting at here. User-Priority-Table does only
> affect the port-based priority settings and is not enforced on a
> per-user or per-session basis.
> 
> MS
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:[email-masked]] 
>>Sent: Wednesday, April 05, 2006 1:07 AM
>>To: Hannes Tschofenig
>>Cc: Sanchez, Mauricio (ProCurve); Bernard Aboba; 
>>[email-masked]
>>Subject: Re: Review of draft-ietf-radext-vlan-02.txt
>>
>>Hi Mauricio,
>>
>>another issue that came to my mind again was raised during 
>>the discussion with Bernard is that the User-Priority-Table 
>>is used for remapping of user priorities only according to 
>>the User Priority Regeneration table. The conclusion of our 
>>discussion was that your draft does not aim to attemp to 
>>associate the actual data traffic with the QoS classes.
>>
>>Ciao
>>Hannes
>>
>>Hannes Tschofenig wrote:
>>
>>>Hi Mauricio,
>>>
>>>thanks for responding to this issue. Please find my response below:
>>>
>>>
>>>>>>your new text proposal looks much better.
>>>>>>
>>>>>>You need to modify Section 3 as well:
>>>>>>
>>>>>>"
>>>>>> Access-   Access-  Access-  Access-    CoA-
>>>>>>  Request   Accept   Reject   Challenge  Req    #   Attribute
>>>>>>    0        0-1      0        0         0-1   TBD  
>>>>>
>>>>>
>>>>>User-Priority-Table
>>>>>
>>>>>
>>>>>>"
>>>>>
>>>>>
>>>>>Got it.   BTW, do you think that *any* of the attributes are 
>>>>>appropriate for inclusion in an Accounting-Request?
>>>>
>>>>
>>>>
>>>>An argument to allow these attributes in an 
>>
>>Accounting-Request is for
>>
>>>>forensic purposes.  The accounting server is already aggregating a
>>>>number of session characteristics (packet/byte counts) and allowing
>>>>attributes from the vlan draft would shed additional light 
>>
>>on the what
>>
>>>>specific services the user was consuming/using at a given 
>>
>>point in time.
>>
>>>Assume that you carry the User-Priority-Table within 
>>
>>Accounting-Request 
>>
>>>messages. Do you think that it provides information how 
>>
>>many packets are 
>>
>>>carried for each individual QoS class? Where is the 
>>
>>information that 
>>
>>>offers me the following info:
>>>- # packets/bytes for user priority 0
>>>....
>>>- # packets/bytes for user priority 7
>>>
>>>Ciao
>>>Hannes
>>>
>>>
>>>>
>>>>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: Fri, 07 Apr 2006 23:13:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Fri, 7 Apr 2006 16:12:54 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I'm not sure what you're getting at here. User-Priority-Table does only
affect the port-based priority settings and is not enforced on a
per-user or per-session basis.

MS

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]=20
> Sent: Wednesday, April 05, 2006 1:07 AM
> To: Hannes Tschofenig
> Cc: Sanchez, Mauricio (ProCurve); Bernard Aboba;=20
> [email-masked]
> Subject: Re: Review of draft-ietf-radext-vlan-02.txt
>=20
> Hi Mauricio,
>=20
> another issue that came to my mind again was raised during=20
> the discussion with Bernard is that the User-Priority-Table=20
> is used for remapping of user priorities only according to=20
> the User Priority Regeneration table. The conclusion of our=20
> discussion was that your draft does not aim to attemp to=20
> associate the actual data traffic with the QoS classes.
>=20
> Ciao
> Hannes
>=20
> Hannes Tschofenig wrote:
> > Hi Mauricio,
> >=20
> > thanks for responding to this issue. Please find my response below:
> >=20
> >>>> your new text proposal looks much better.
> >>>>
> >>>> You need to modify Section 3 as well:
> >>>>
> >>>> "
> >>>>  Access-   Access-  Access-  Access-    CoA-
> >>>>   Request   Accept   Reject   Challenge  Req    #   Attribute
> >>>>     0        0-1      0        0         0-1   TBD =20
> >>>
> >>>
> >>> User-Priority-Table
> >>>
> >>>> "
> >>>
> >>>
> >>> Got it.   BTW, do you think that *any* of the attributes are=20
> >>> appropriate for inclusion in an Accounting-Request?
> >>
> >>
> >>
> >> An argument to allow these attributes in an=20
> Accounting-Request is for
> >> forensic purposes.  The accounting server is already aggregating a
> >> number of session characteristics (packet/byte counts) and allowing
> >> attributes from the vlan draft would shed additional light=20
> on the what
> >> specific services the user was consuming/using at a given=20
> point in time.
> >=20
> > Assume that you carry the User-Priority-Table within=20
> Accounting-Request=20
> > messages. Do you think that it provides information how=20
> many packets are=20
> > carried for each individual QoS class? Where is the=20
> information that=20
> > offers me the following info:
> > - # packets/bytes for user priority 0
> > ....
> > - # packets/bytes for user priority 7
> >=20
> > Ciao
> > Hannes
> >=20
> >>
> >>
> >> Cheers,
> >> MS
> >=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/>

Delivery-date: Wed, 05 Apr 2006 21:41:37 +0000
Date: Wed, 05 Apr 2006 09:08:53 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Mauricio,

thanks for responding to this issue. Please find my response below:

>>>your new text proposal looks much better.
>>>
>>>You need to modify Section 3 as well:
>>>
>>>"
>>>  Access-   Access-  Access-  Access-    CoA-
>>>   Request   Accept   Reject   Challenge  Req    #   Attribute
>>>     0        0-1      0        0         0-1   TBD  
>>
>>User-Priority-Table
>>
>>>"
>>
>>Got it.   BTW, do you think that *any* of the attributes are 
>>appropriate for 
>>inclusion in an Accounting-Request?
> 
> 
> An argument to allow these attributes in an Accounting-Request is for
> forensic purposes.  The accounting server is already aggregating a
> number of session characteristics (packet/byte counts) and allowing
> attributes from the vlan draft would shed additional light on the what
> specific services the user was consuming/using at a given point in time.
Assume that you carry the User-Priority-Table within Accounting-Request 
messages. Do you think that it provides information how many packets are 
carried for each individual QoS class? Where is the information that 
offers me the following info:
- # packets/bytes for user priority 0
...
- # packets/bytes for user priority 7

Ciao
Hannes

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

--
to unsubscribe send a message 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, 05 Apr 2006 21:27:47 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Thu, 6 Apr 2006 00:27:29 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>, <[email-masked]>

=20
=20

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20

> Not to be tedious, but I was hardly suggesting that entities=20
> lie about discontinuities.  Rather, perhaps by using a buddy=20
> system or a central collection point, avoid them.  The issue=20
> is the extent to which outside entities need to be aware of=20
> the distributed nature of some managed entity, or whether the=20
> entity should take pains to present a unitary appearance to=20
> the world.  There seems to be little stylistic guidance on=20
> this point, which becomes ever more relevant.  Your last=20
> sentence gives fine guidance for a vendor MIB on a particular=20
> design, but not, I submit, for a standard.
>=20
> Barney Wolff
>=20

This is not stylistic guidance, and unitary appearance to the world is
not important, certainly not at the cost of exposing information known
to be inaccurate.  If the system has the capability of detecting
discontinuities at a better granularity, discontinuity objects should
reflect this.=20

Dan

--
to unsubscribe send a message 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, 05 Apr 2006 20:36:05 +0000
Date: Wed, 05 Apr 2006 09:08:53 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Mauricio,

thanks for responding to this issue. Please find my response below:

>>>your new text proposal looks much better.
>>>
>>>You need to modify Section 3 as well:
>>>
>>>"
>>>  Access-   Access-  Access-  Access-    CoA-
>>>   Request   Accept   Reject   Challenge  Req    #   Attribute
>>>     0        0-1      0        0         0-1   TBD  
>>
>>User-Priority-Table
>>
>>>"
>>
>>Got it.   BTW, do you think that *any* of the attributes are 
>>appropriate for 
>>inclusion in an Accounting-Request?
> 
> 
> An argument to allow these attributes in an Accounting-Request is for
> forensic purposes.  The accounting server is already aggregating a
> number of session characteristics (packet/byte counts) and allowing
> attributes from the vlan draft would shed additional light on the what
> specific services the user was consuming/using at a given point in time.
Assume that you carry the User-Priority-Table within Accounting-Request 
messages. Do you think that it provides information how many packets are 
carried for each individual QoS class? Where is the information that 
offers me the following info:
- # packets/bytes for user priority 0
....
- # packets/bytes for user priority 7

Ciao
Hannes

> 
> 
> 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: Wed, 05 Apr 2006 20:07:51 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 15:06:18 -0500
From: "Carl Kalbfleisch" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

I think the model is the interface MIB which provides discontinuity per =
interface.

Carl

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 3:05 PM
> To: Romascanu, Dan (Dan)
> Cc: Nelson, David; [email-masked]; Carl Kalbfleisch;
> [email-masked]
> Subject: Re: looking for advise on RFC-2618 and 2620
>=20
>=20
> On Wed, Apr 05, 2006 at 08:48:09PM +0300, Romascanu, Dan (Dan) wrote:
> > >=20
> > > RADIUS can hardly be the only potentially distributed=20
> > > application with this problem.  Perhaps mib-doctors can be=20
> > > asked how others have solved it, or determined that such=20
> > > internal issues must be kept hidden.
> >=20
> > Hiding is certainly not good. Counter discontinuity objects=20
> should be
> > defined when discontinuities happen at other time than
> > re-initialization, as per RFC 2578, Sections 7.1.6 and=20
> 7.1.10 and RFC
> > 4181 Section 4.6.1.2. The granularity of the discontinuity objects
> > (global, per table, per row) is a function of whether=20
> discontinuities
> > happen globally, or per interface, etc.=20
>=20
> Not to be tedious, but I was hardly suggesting that entities lie about
> discontinuities.  Rather, perhaps by using a buddy system or a central
> collection point, avoid them.  The issue is the extent to=20
> which outside
> entities need to be aware of the distributed nature of some managed
> entity, or whether the entity should take pains to present a unitary
> appearance to the world.  There seems to be little stylistic guidance
> on this point, which becomes ever more relevant.  Your last sentence
> gives fine guidance for a vendor MIB on a particular design, but not,
> I submit, for a standard.
>=20
> Barney Wolff
>=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, 05 Apr 2006 20:06:30 +0000
Date: Wed, 5 Apr 2006 16:05:24 -0400
From: Barney Wolff <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked], Carl Kalbfleisch <[email-masked]>, [email-masked]
Subject: Re: looking for advise on RFC-2618 and 2620

On Wed, Apr 05, 2006 at 08:48:09PM +0300, Romascanu, Dan (Dan) wrote:
> > 
> > RADIUS can hardly be the only potentially distributed 
> > application with this problem.  Perhaps mib-doctors can be 
> > asked how others have solved it, or determined that such 
> > internal issues must be kept hidden.
> 
> Hiding is certainly not good. Counter discontinuity objects should be
> defined when discontinuities happen at other time than
> re-initialization, as per RFC 2578, Sections 7.1.6 and 7.1.10 and RFC
> 4181 Section 4.6.1.2. The granularity of the discontinuity objects
> (global, per table, per row) is a function of whether discontinuities
> happen globally, or per interface, etc. 

Not to be tedious, but I was hardly suggesting that entities lie about
discontinuities.  Rather, perhaps by using a buddy system or a central
collection point, avoid them.  The issue is the extent to which outside
entities need to be aware of the distributed nature of some managed
entity, or whether the entity should take pains to present a unitary
appearance to the world.  There seems to be little stylistic guidance
on this point, which becomes ever more relevant.  Your last sentence
gives fine guidance for a vendor MIB on a particular design, but not,
I submit, for a standard.

Barney Wolff

--
to unsubscribe send a message 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, 05 Apr 2006 19:13:51 +0000
Date: Wed, 05 Apr 2006 10:06:45 +0200
From: Hannes Tschofenig <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: "Sanchez, Mauricio (ProCurve)" <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Mauricio,

another issue that came to my mind again was raised during the 
discussion with Bernard is that the User-Priority-Table is used for 
remapping of user priorities only according to the User Priority 
Regeneration table. The conclusion of our discussion was that your draft 
does not aim to attemp to associate the actual data traffic with the QoS 
classes.

Ciao
Hannes

Hannes Tschofenig wrote:
> Hi Mauricio,
> 
> thanks for responding to this issue. Please find my response below:
> 
>>>> your new text proposal looks much better.
>>>>
>>>> You need to modify Section 3 as well:
>>>>
>>>> "
>>>>  Access-   Access-  Access-  Access-    CoA-
>>>>   Request   Accept   Reject   Challenge  Req    #   Attribute
>>>>     0        0-1      0        0         0-1   TBD  
>>>
>>>
>>> User-Priority-Table
>>>
>>>> "
>>>
>>>
>>> Got it.   BTW, do you think that *any* of the attributes are 
>>> appropriate for inclusion in an Accounting-Request?
>>
>>
>>
>> An argument to allow these attributes in an Accounting-Request is for
>> forensic purposes.  The accounting server is already aggregating a
>> number of session characteristics (packet/byte counts) and allowing
>> attributes from the vlan draft would shed additional light on the what
>> specific services the user was consuming/using at a given point in time.
> 
> Assume that you carry the User-Priority-Table within Accounting-Request 
> messages. Do you think that it provides information how many packets are 
> carried for each individual QoS class? Where is the information that 
> offers me the following info:
> - # packets/bytes for user priority 0
> ....
> - # packets/bytes for user priority 7
> 
> Ciao
> Hannes
> 
>>
>>
>> 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: Wed, 05 Apr 2006 17:48:23 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 20:48:09 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20
> Sent: Wednesday, April 05, 2006 8:11 PM
> To: Nelson, David
> Cc: [email-masked]; Carl Kalbfleisch;=20
> Romascanu, Dan (Dan); [email-masked]
> Subject: Re: looking for advise on RFC-2618 and 2620
>=20
> On Wed, Apr 05, 2006 at 01:00:39PM -0400, Nelson, David wrote:
> > Stefaan DeCnodder writes...
> >=20
> > > Dave, the current version 05 was intended for IESG=20
> review. Should we=20
> > > wait for the IESG review to be finished or submit a version 06 as=20
> > > soon as possible?
> >=20
> > The suggestion for added granularity of the discontinuity timestamp=20
> > (i.e. per row) seems reasonable.  However, the MIBs in=20
> question (all=20
> > six of them) have completed RADEXT WGLC and are now in AD Review. =20
> > There may be an opportunity for such comments to be made on=20
> at least=20
> > some of these MIBs as they go to IESG last call.  The=20
> editors should=20
> > not be responding to comments from the WG at this time.
> >=20
> > I would like to ask the Shepherding AD, Dan Romascanu, whether he=20
> > thinks that the comments about additional granularity of=20
> the counter=20
> > discontinuity indicators are meritorious, and should be=20
> included in a=20
> > revised draft at this point in time?
>=20
> RADIUS can hardly be the only potentially distributed=20
> application with this problem.  Perhaps mib-doctors can be=20
> asked how others have solved it, or determined that such=20
> internal issues must be kept hidden.
>=20
> Barney Wolff
>=20

Hiding is certainly not good. Counter discontinuity objects should be
defined when discontinuities happen at other time than
re-initialization, as per RFC 2578, Sections 7.1.6 and 7.1.10 and RFC
4181 Section 4.6.1.2. The granularity of the discontinuity objects
(global, per table, per row) is a function of whether discontinuities
happen globally, or per interface, etc.=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, 05 Apr 2006 17:36:50 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 20:36:44 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>
Cc: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "David Kessens" <[email-masked]>

Actually Bert's recommendation in the tracker was that the 02 versions
of the "bis" MIB docs could go to LC, with the AD review comments as
entering comments. What you suggest is even better, so I will wait for
the 03 round before issuing the LC.=20

Dan

=20
=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Wednesday, April 05, 2006 8:33 PM
> To: Romascanu, Dan (Dan); [email-masked]; Carl=20
> Kalbfleisch
> Cc: [email-masked]; Wijnen, Bert (Bert); David Kessens
> Subject: RE: looking for advise on RFC-2618 and 2620
>=20
> Dab Romascanu writes...
>=20
> > My proposal is to go ahead with the IESG LC on the existing=20
> documents=20
> > (all six of them) and have the comments submitted as LC comments.
>=20
> This is fine with me.  I wanted to clarify, however, that my=20
> intent was to issue version -03 of the four "bis" MIB=20
> documents, to bring them into "sync" with the dynauth MIBs at=20
> -05, based on the AD comments already received.  I have yet=20
> to complete that revision.
>=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/>

Delivery-date: Wed, 05 Apr 2006 17:33:38 +0000
Content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 13:32:45 -0400
From: "Nelson, David" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>
Cc: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "David Kessens" <[email-masked]>

Dab Romascanu writes...

> My proposal is to go ahead with the IESG LC on the existing documents
> (all six of them) and have the comments submitted as LC comments.

This is fine with me.  I wanted to clarify, however, that my intent was
to issue version -03 of the four "bis" MIB documents, to bring them into
"sync" with the dynauth MIBs at -05, based on the AD comments already
received.  I have yet to complete that revision.

--
to unsubscribe send a message 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, 05 Apr 2006 17:27:38 +0000
content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 20:27:27 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>
Cc: <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>, "David Kessens" <[email-masked]>

My proposal is to go ahead with the IESG LC on the existing documents
(all six of them) and have the comments submitted as LC comments.=20

Anybody sees any problem?=20

Dan

=20
=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Wednesday, April 05, 2006 8:01 PM
> To: [email-masked]; Carl Kalbfleisch;=20
> Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: looking for advise on RFC-2618 and 2620
>=20
> Stefaan DeCnodder writes...
>=20
> > Dave, the current version 05 was intended for IESG review.=20
> Should we=20
> > wait for the IESG review to be finished or submit a version=20
> 06 as soon=20
> > as possible?
>=20
> The suggestion for added granularity of the discontinuity=20
> timestamp (i.e. per row) seems reasonable.  However, the MIBs=20
> in question (all six of them) have completed RADEXT WGLC and=20
> are now in AD Review.  There may be an opportunity for such=20
> comments to be made on at least some of these MIBs as they go=20
> to IESG last call.  The editors should not be responding to=20
> comments from the WG at this time.
>=20
> I would like to ask the Shepherding AD, Dan Romascanu,=20
> whether he thinks that the comments about additional=20
> granularity of the counter discontinuity indicators are=20
> meritorious, and should be included in a revised draft at=20
> this point in time?
>=20
> -- Dave
>=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: Wed, 05 Apr 2006 17:11:55 +0000
Date: Wed, 5 Apr 2006 13:11:28 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], Carl Kalbfleisch <[email-masked]>, "Dan Romascanu (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: looking for advise on RFC-2618 and 2620

On Wed, Apr 05, 2006 at 01:00:39PM -0400, Nelson, David wrote:
> Stefaan DeCnodder writes...
> 
> > Dave, the current version 05 was intended for IESG review. Should we
> > wait for the IESG review to be finished or submit a version 06 as soon
> > as possible?
> 
> The suggestion for added granularity of the discontinuity timestamp
> (i.e. per row) seems reasonable.  However, the MIBs in question (all six
> of them) have completed RADEXT WGLC and are now in AD Review.  There may
> be an opportunity for such comments to be made on at least some of these
> MIBs as they go to IESG last call.  The editors should not be responding
> to comments from the WG at this time.
> 
> I would like to ask the Shepherding AD, Dan Romascanu, whether he thinks
> that the comments about additional granularity of the counter
> discontinuity indicators are meritorious, and should be included in a
> revised draft at this point in time?

RADIUS can hardly be the only potentially distributed application with
this problem.  Perhaps mib-doctors can be asked how others have solved
it, or determined that such internal issues must be kept hidden.

Barney Wolff

--
to unsubscribe send a message 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, 05 Apr 2006 17:01:23 +0000
Content-class: urn:content-classes:message
Subject: RE: looking for advise on RFC-2618 and 2620
Date: Wed, 5 Apr 2006 13:00:39 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Carl Kalbfleisch" <[email-masked]>, "Dan Romascanu \(E-mail\)" <[email-masked]>
Cc: <[email-masked]>

Stefaan DeCnodder writes...

> Dave, the current version 05 was intended for IESG review. Should we
> wait for the IESG review to be finished or submit a version 06 as soon
> as possible?

The suggestion for added granularity of the discontinuity timestamp
(i.e. per row) seems reasonable.  However, the MIBs in question (all six
of them) have completed RADEXT WGLC and are now in AD Review.  There may
be an opportunity for such comments to be made on at least some of these
MIBs as they go to IESG last call.  The editors should not be responding
to comments from the WG at this time.

I would like to ask the Shepherding AD, Dan Romascanu, whether he thinks
that the comments about additional granularity of the counter
discontinuity indicators are meritorious, and should be included in a
revised draft at this point in time?

-- 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, 05 Apr 2006 13:37:39 +0000
Date: Wed, 05 Apr 2006 15:37:01 +0200
From: [email-masked]
To: Carl Kalbfleisch <[email-masked]>, "Nelson, David" <[email-masked]>
CC: [email-masked]
Subject: Re: looking for advise on RFC-2618 and 2620

Hi Carl,

> 
> 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."
>           ::= { radiusDynAuthClientScalars 3 }
> 
> I recommend adding this attribute to the RadiusDynAuthServerEntry instead.

I believe the discontinuity timer at MIB level is still needed for some 
scalars, and to have them in the table itself for each entry seems to be 
like a good idea based on your explanation.

Dave, the current version 05 was intended for IESG review. Should we 
wait for the IESG review to be finished or submit a version 06 as soon 
as possible?

regards,
Stefaan

  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.
>>
>>That seems like a reasonable suggestion.
>>
> 
> 
> 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 
>>
>>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?
>>
>>
> 
> 
> 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/>

--
to unsubscribe send a message 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, 04 Apr 2006 23:58:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Tue, 4 Apr 2006 16:56:58 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, April 02, 2006 7:14 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-radext-vlan-02.txt
>=20
>=20
> >your new text proposal looks much better.
> >
> >You need to modify Section 3 as well:
> >
> >"
> >   Access-   Access-  Access-  Access-    CoA-
> >    Request   Accept   Reject   Challenge  Req    #   Attribute
> >      0        0-1      0        0         0-1   TBD =20
> User-Priority-Table
> >"
>=20
> Got it.   BTW, do you think that *any* of the attributes are=20
> appropriate for=20
> inclusion in an Accounting-Request?

An argument to allow these attributes in an Accounting-Request is for
forensic purposes.  The accounting server is already aggregating a
number of session characteristics (packet/byte counts) and allowing
attributes from the vlan draft would shed additional light on the what
specific services the user was consuming/using at a given point in time.

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: Tue, 04 Apr 2006 23:02:46 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: VLAN-03 strawman
Date: Tue, 04 Apr 2006 16:02:20 -0700

As we work to put the remaining issue(s) to bed on the VLAN/priority draft, 
I thought it would be helpful to have a strawman document reflecting where I 
think we are at the moment:

http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-03.txt

The current version reflects Paul's most recent editorial issues posting, as 
well as a cleanup of the reference section (several references were not 
actually referenced in the text).   Note also the addition of text 
discouraging use of the attributes in Accounting-Requests (from Hannes' 
issue).

Comments solicited.

--
to unsubscribe send a message 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, 04 Apr 2006 17:50:12 +0000
Date: Tue, 04 Apr 2006 14:23:01 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Paul,

>>The question whether to provide the table only for a single 
>>port was resolved. Whether the table is actually user 
>>specific is another question. As such, the table would be 
>>indexed using the port number and the user "identity".
>>
> 
> 
> The table, as defined by 802.1D, is a per-port table.  There is no
> facility within 802.1D to make this a per-user table.
Hmmm. This is then a bit surprising for me since RADIUS usage for the
User-Priority-Table attribute would then also be for user and not only 
for the port. An IEEE 802.1D implementation would have to store 1 
User-Priority-Table per port but with the mechanism proposed in your 
document (draft-ietf-radext-vlan-02.txt) there has to be 
N*User-Priority-Tables for a particular port, whereby N is the number of 
users attached to a particular port.

Do I miss something here?

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: Tue, 04 Apr 2006 16:39:49 +0000
Date: Tue, 04 Apr 2006 14:39:09 +0200
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Tricky!

Bernard Aboba wrote:
>> Do I miss something here?
> 
> 
> In IEEE 802.1X-2004, there is an implicit assumption that there is only 
> one user per port.
> If there is more than one user on a shared medium (as in 802.11), then a 
> "virtual port" is created, so that this is not as restrictive as it 
> might seem at first glance.
> 
> 
> 
> -- 
> to unsubscribe send 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, 04 Apr 2006 13:56:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Tue, 4 Apr 2006 06:55:56 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Yes, actually, the more I think about this the more I agree that we
probably need some additional text here because things are not as simple
as they seem...  The draft is not very clear about how we are
programming the PVID (ingress untagged VLAN) verses the egress list
(tagged and untagged VLANs on egress). This is a very subtle detail
about VLANs that probably needs to be made more obvious... =20

There are a number of question... If there are multiple untagged VLANs,
which one is supposed to be used for the PVID (ingress)?  Is that the
one that is configured by the Tunnel attributes specified by RFC 3580?
What happens if the same VLAN is listed in this attributed?  What
happens if it is tagged in this attribute and specified as untagged in
the Tunnel attribute?

I think I'm going to want to consult some of the experts in 802.1 before
proposing text here...

Paul

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Tuesday, April 04, 2006 5:11 AM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
>=20
> >Yes you are missing the subtle fact that it is only possible to=20
> >classify a single port-based untagged VLAN in ingress. =20
> There is only=20
> >one PVID per port to map incoming untagged frames to, but=20
> there may be=20
> >several untagged VLANs on egress.
>=20
> Would it be possible to craft some text to describe this?
>=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/>

Delivery-date: Tue, 04 Apr 2006 12:27:30 +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: Tue, 04 Apr 2006 05:27:18 -0700

>Do I miss something here?

In IEEE 802.1X-2004, there is an implicit assumption that there is only one 
user per port.
If there is more than one user on a shared medium (as in 802.11), then a 
"virtual port" is created, so that this is not as restrictive as it might 
seem at first glance.

--
to unsubscribe send a message 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, 04 Apr 2006 12:11:40 +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: Tue, 04 Apr 2006 05:10:35 -0700

>Yes you are missing the subtle fact that it is only possible to classify
>a single port-based untagged VLAN in ingress.  There is only one PVID
>per port to map incoming untagged frames to, but there may be several
>untagged VLANs on egress.

Would it be possible to craft some text to describe this?

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

Delivery-date: Mon, 03 Apr 2006 16:46:03 +0000
Content-class: urn:content-classes:message
Subject: VLAN-02 comments
Date: Mon, 3 Apr 2006 09:45:50 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Sanchez, Mauricio (ProCurve)" <[email-masked]>

I've read the latest version of the draft and believe it is in very good
shape.  I have a couple of editorial comments, but they are not binding
and should not hold up any further progress.

1. Reference to Token Ring standard.  I believe we discussed this in
previous threads, but there is no reference to the Token Ring standard
as there is to 802.3 and 802.11 in the opening sentence of the
Introduction.  We could either eliminate Token Ring from the list in
this sentence or provide a reference.  I'm not aware of any use of VLANs
on Token Ring, so I would recommend removing it from the sentence.  If,
however, we decide to provide a reference instead, the reference is,
"[IEEE 802.5] 8802-5-1998 (IEEE Std 802.5-1998) Token Ring Access Method
and Physical Layer Specifications"

2. Most of the terms defined in the Terminology section are not used
anymore in this document.  This was checked by doing a search.
Certainly "backend authentication server" and "Supplicant" can be
removed.  "Authenticator" is really only used in the 1st sentence of the
abstract and could easily be removed as well and (if necessary) tweak
the abstract.

Paul

--
to unsubscribe send a message 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, 03 Apr 2006 16:37:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 3 Apr 2006 09:37:48 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> > =20
> >=20
> >>I hope that it was indeed the intention to have this table per-port=20
> >>and also per-user. Section 14.6.2 does not give me this impression.
> >>Shouldn't Section 14.6.2 also mentions this aspect as well.
> >>
> >=20
> >=20
> > Sounds like Bernard's new text satisfies this comment, but=20
> just want=20
> > to clarify that we are talking about a "per-port"=20
> configuration table=20
> > as defined by 802.1D.
>=20
> The question whether to provide the table only for a single=20
> port was resolved. Whether the table is actually user=20
> specific is another question. As such, the table would be=20
> indexed using the port number and the user "identity".
>=20

The table, as defined by 802.1D, is a per-port table.  There is no
facility within 802.1D to make this a per-user table.
=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, 03 Apr 2006 16:35:51 +0000
Date: Mon, 03 Apr 2006 18:35:26 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Paul,

Congdon, Paul T (ProCurve) wrote:
>  
> 
>>I hope that it was indeed the intention to have this table 
>>per-port and also per-user. Section 14.6.2 does not give me 
>>this impression. 
>>Shouldn't Section 14.6.2 also mentions this aspect as well.
>>
> 
> 
> Sounds like Bernard's new text satisfies this comment, but just want to
> clarify that we are talking about a "per-port" configuration table as
> defined by 802.1D. 

The question whether to provide the table only for a single port was 
resolved. Whether the table is actually user specific is another 
question. As such, the table would be indexed using the port number and 
the user "identity".

> 
> Paul
> 
> 

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: Mon, 03 Apr 2006 16:13:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 3 Apr 2006 09:13:08 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Yes you are missing the subtle fact that it is only possible to classify
a single port-based untagged VLAN in ingress.  There is only one PVID
per port to map incoming untagged frames to, but there may be several
untagged VLANs on egress.

Paul=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, April 03, 2006 9:09 AM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
>=20
> >I don't think you can or should define this type of=20
> restriction.  It is=20
> >completely valid behavior to allow multiple untagged VLANs=20
> on egress in=20
> >a standard 802.1Q bridge.  There are certain features (e.g. private
> >VLANs) that would like to have this type of configuration enabled. =20
> >When 'ingress filters' are enabled, this is prohibited, so there are=20
> >ways to avoid the concern you have without forcing the use=20
> of Radius to=20
> >be incompatible with the 802.1Q standard.
>=20
> Here's what the Ingress-Filters attribute description says:
>=20
>       The Ingress-Filters attribute corresponds to the Ingress Filter
>       per-port variable defined in [IEEE-802.1Q] clause=20
> 8.4.5.  When the
>       attribute has the value "Enabled", the set of VLANs that are
>       allowed to ingress a port must match the set of VLANs that are
>       allowed to egress a port.
>=20
> From this text, I'd assume that it would be legal to have=20
> both Ingress-Filters "Enabled" and multiple untagged=20
> Egress-VLANIDs/Names attributes.  Or am I missing something? =20
> If there is a usage restriction here, I think we need to=20
> describe what it is.
>=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/>

Delivery-date: Mon, 03 Apr 2006 16:09:16 +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: Mon, 03 Apr 2006 09:09:02 -0700

>I don't think you can or should define this type of restriction.  It is
>completely valid behavior to allow multiple untagged VLANs on egress in
>a standard 802.1Q bridge.  There are certain features (e.g. private
>VLANs) that would like to have this type of configuration enabled.  When
>'ingress filters' are enabled, this is prohibited, so there are ways to
>avoid the concern you have without forcing the use of Radius to be
>incompatible with the 802.1Q standard.

Here's what the Ingress-Filters attribute description says:

      The Ingress-Filters attribute corresponds to the Ingress Filter
      per-port variable defined in [IEEE-802.1Q] clause 8.4.5.  When the
      attribute has the value "Enabled", the set of VLANs that are
      allowed to ingress a port must match the set of VLANs that are
      allowed to egress a port.

>From this text, I'd assume that it would be legal to have both 
Ingress-Filters "Enabled" and multiple untagged Egress-VLANIDs/Names 
attributes.  Or am I missing something?  If there is a usage restriction 
here, I think we need to describe what it is.

--
to unsubscribe send a message 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, 03 Apr 2006 16:04:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Location draft issues raised today
Date: Mon, 03 Apr 2006 09:03:56 -0700

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

In this particular case, the question is whether the RADIUS server would 
need to define policy based on the individual geospatial and civil location 
elements.

For geospatial location, this would be equivalent to asking whether the 
RADIUS server would need to parse the geospatial data, or would just pass it 
to a location module for the authorization decision.  If we are talking 
about determining whether the geospatial location is within a well defined 
boundary (e.g. a manufacturing plant), then I suspect that a special module 
would make that determination, not a standard RADIUS server policy engine.  
While it is possible that the RADIUS server would want to ask questions like 
"Is the client above or below the equator?" I suspect that this will be 
relatively rare. So there seems to be a plausible argument that Geospatial 
location need not be parsed by the RADIUS server.

However, I do not think that this argument is as convincing for civil 
location.  For example, could RADIUS server policy depend on the country or 
state that the user is accessing the network from?  This seems somewhat 
likely.

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

The location structures used in this document are largely derived from RFC 
3825 (Geospatial) and
draft-ietf-geopriv-dhcp-civil-09.txt.  However, in those documents, the DHCP 
server is providing data to the client, and therefore the policy issues 
discussed above did not come up.  Rather the issue was only the creation of 
UI for the administrator to enter the data.

However, there are substantial issues with attempting to allocate a single 
RADIUS attribute for each
Civil Address type (CAtype) described in 
draft-ietf-geopriv-dhcp-civil-09.txt:

a. It is possible for the attribute to refer to the NAS or user location, 
and therefore it is possible for both locations to be communicated in the 
same message. This implies that separating the elements would require a 
tagging format to be used.

b. There are a considerable number of CAtype values.  Aside from Country 
Code, there are 39 values allocated, with allocation of up to 254 value 
possible (the value 255 is reserved).   Therefore allocating CAtype values 
out of the standard RADIUS attribute space would in practice be difficult, 
because separate CAtype and RADIUS type allocations would be needed for each 
new value.  Also, the CAtype allocation collides with existing RADIUS type 
allocations defined in RFC 3575.  Therefore it is not clear to me that 
mapping the CAtype into the RADIUS type space is a good idea.

Given this, my conclusions are as follows:

a. Civil and Geospatial location should *not* be encoded in the same 
attribute.
b. Civil location should not be encoded as separate standard RADIUS 
attributes;  it is not even clear to me that a Diameter-compatible format 
(with grouping) would work well for this.

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

Delivery-date: Mon, 03 Apr 2006 15:57:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 3 Apr 2006 08:57:40 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

=20
>=20
> I hope that it was indeed the intention to have this table=20
> per-port and also per-user. Section 14.6.2 does not give me=20
> this impression.=20
> Shouldn't Section 14.6.2 also mentions this aspect as well.
>

Sounds like Bernard's new text satisfies this comment, but just want to
clarify that we are talking about a "per-port" configuration table as
defined by 802.1D.=20

Paul

--
to unsubscribe send a message 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, 03 Apr 2006 15:53:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-vlan-02.txt
Date: Mon, 3 Apr 2006 08:53:15 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20
>=20
> BTW, I just thought of another issue.  If not careful, it is=20
> quite possible for the administrator to cause considerable=20
> chaos with these attributes. =20
> For example, it would be possible to configure multiple=20
> untagged Egress-VLANIDs or Egress-VLAN-Name attributes,=20
> effectively connecting multiple broadcast domains together.
>=20
> I am thinking that it should only be possible to send at most=20
> a single Untagged Egress-VLANID, or Egress-VLAN-Name=20
> attribute in an Access-Accept, which makes me wonder whether=20
> there shouldn't be two separate attributes for=20
> Tagged-Egress-VLANID/Name (0+) and Untagged-Egress-VLANID/Name (0-1).
>=20

I don't think you can or should define this type of restriction.  It is
completely valid behavior to allow multiple untagged VLANs on egress in
a standard 802.1Q bridge.  There are certain features (e.g. private
VLANs) that would like to have this type of configuration enabled.  When
'ingress filters' are enabled, this is prohibited, so there are ways to
avoid the concern you have without forcing the use of Radius to be
incompatible with the 802.1Q standard.

Paul

--
to unsubscribe send a message 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, 03 Apr 2006 02:14:35 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Review of draft-ietf-radext-vlan-02.txt
Date: Sun, 02 Apr 2006 19:14:00 -0700

>your new text proposal looks much better.
>
>You need to modify Section 3 as well:
>
>"
>   Access-   Access-  Access-  Access-    CoA-
>    Request   Accept   Reject   Challenge  Req    #   Attribute
>      0        0-1      0        0         0-1   TBD  User-Priority-Table
>"

Got it.   BTW, do you think that *any* of the attributes are appropriate for 
inclusion in an Accounting-Request?

BTW, I just thought of another issue.  If not careful, it is quite possible 
for the administrator to cause considerable chaos with these attributes.  
For example, it would be possible to configure multiple untagged 
Egress-VLANIDs or Egress-VLAN-Name attributes, effectively connecting 
multiple broadcast domains together.

I am thinking that it should only be possible to send at most a single 
Untagged Egress-VLANID, or Egress-VLAN-Name attribute in an Access-Accept, 
which makes me wonder whether there shouldn't be two separate attributes for 
Tagged-Egress-VLANID/Name (0+) and Untagged-Egress-VLANID/Name (0-1).

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

Delivery-date: Sun, 02 Apr 2006 20:08:20 +0000
Date: Sun, 02 Apr 2006 22:07:32 +0200
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Bernard,

your new text proposal looks much better.

You need to modify Section 3 as well:

"
   Access-   Access-  Access-  Access-    CoA-
    Request   Accept   Reject   Challenge  Req    #   Attribute
      0        0-1      0        0         0-1   TBD  User-Priority-Table
"

A small comment below:

Bernard Aboba wrote:
> Let's see if we can come up with text changes to address the issues that 
> we've discussed on this thread.
> 
> First off, it seems like we need to include information on what 
> attributes (if any) are allowed in an Accounting-Request.  Since use in 
> an Accounting-Request is not mentioned for any attributes, by default, 
> I'd assume that none of the attributes are valid in an 
> Accounting-Request, but I wanted to make sure this is the case.
> 
> Here is a potential rewrite of Section 2.4:
> 
> 2.4.  User-Priority-Table
> 
>   Description
> 
>      [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map)
>      user priority on frames received at a port.  This per-port
>      configuration enables a bridge to cause the priority of received
>      traffic at a port to be mapped to a particular priority.
>      [IEEE-802.1D] clause 6.3.9 states:
> 
>         The ability to signal user priority in IEEE 802 LANs allows
>         user priority to be carried with end-to-end significance across
>         a Bridged Local Area Network.  This, coupled with a consistent
>         approach to the mapping of user priority to traffic classes and
>         of user priority to access_priority, allows consistent use of
>         priority information, according to the capabilities of the
>         Bridges and MACs in the transmission path...
> 
>         Under normal circumstances, user priority is not modified in
>         transit through the relay function of a Bridge; however,
>         network management can control how user priority is propagated.
>         Table 7-1 provides the ability to map incoming user priority
>         values on a per-Port basis. By default, the regenerated user
>         priority is identical to the incoming user priority.
> 
>      This attribute represents the IEEE 802 prioritization that will be
>      applied to packets arriving at this port.  There are eight
>      possible user priorities, according to the [IEEE-802] standard.
>      [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table
>      as 8 values, each an integer in the range 0-7.  By default, no
>      remapping occurs.  The management variables are described in
>      clause 14.6.2.2.
> 
>      A single User-Priority-Table attribute MAY be included in an
>      Access-Accept or CoA-Request packet; this attribute MUST NOT be
>      sent within an Access-Request, Access-Challenge, Access-Reject,
>      Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or
>      CoA-NAK.  Since the regeneration table is only maintained by a
>      bridge conforming to [IEEE-802.1D], this attribute should only be
>      sent to a RADIUS client supporting that specification. 

Maybe you want to add the following sentence:

A RADIUS server that receives the User-Priority-Table attribute
although it does not understand it MUST silently discard it.

> 
>      The User-Priority-Table attribute is shown below.  The fields are
>      transmitted from left to right:
> 
>       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       |          String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    String            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   Type
> 
>      TBD
> 
>   Length
> 
>      10
> 
>   String
> 
>      The String field is 8 octets in length, and includes a table which
>      maps the incoming priority (if it is set - the default is 0) into
>      one of eight regenerated priorities.  The first octet maps to
>      incoming priority 0, the second octet to incoming priority 1, etc.
>      The values in each octet represent the regenerated priority of the
>      packet.
> 
>      It is thus possible to either remap incoming priorities to more
>      appropriate values; to honor the incoming priorities; or to
>      override any incoming priorities, forcing them to all map to a
>      single chosen priority.
> 
>      The [IEEE-8021.D] specification, Annex G, provides a useful
>      description of traffic type - traffic class mappings.

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: Sun, 02 Apr 2006 20:08:13 +0000
Date: Sun, 02 Apr 2006 22:07:28 +0200
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Bernard,

Bernard Aboba wrote:
>> Section 14.6.2 also mentiones that the User Priority Regeneration Table
>> is for a specific port. Hence, I guess you have to send one User
>> Priority Regeneration Table for each port and the User-Priority-Table 
>> attribute then has to appear more than once (and has to refer to the
>> respective port) in the Access-Accept.
> 
> 
> I'd assume that the User-Priority-Table attribute implicitly refers to 
> the NAS-Port attribute included in the Access-Request.  I don't think it 
> is appropriate for the RADIUS server to attempt to set the 
> User-Priority-Table attribute for another port (since that port might 
> not even be in use by a user within the RADIUS server's home realm).

That's a very good point.

I hope that it was indeed the intention to have this table per-port and 
also per-user. Section 14.6.2 does not give me this impression. 
Shouldn't Section 14.6.2 also mentions this aspect as well.

> 
>> I think you just want to delete the usage of the  User-Priority-Table
>> attribute in the Access-Request.
> 
> 
> Unless someone can describe why this would be useful, you're probably 
> right.
> 
>> It seems that you need to add a little bit more text to the draft to 
>> explain based on your response.
> 
> 
> A few paragraphs explaining the 802.1D model and how it would be applied 
> definitely seems in order.
> 
>> I went throught the spec in more detail and I came to the following 
>> (probably tentative) conclusion.
>>
>> Section 6.3.9 (Frame Priority) gave some additional information:
>>
>> "The ability to signal user priority in IEEE 802 LANs allows user 
>> priority to be carried with end-to-end significance across a Bridged 
>> Local Area Network. This, coupled with a consistent approach to the 
>> mapping of user priority to traffic classes and of user priority to 
>> access_priority, allows consistent use of priority information, 
>> according to the capabilities of the Bridges and MACs in the 
>> transmission path."
>>
>> As such, the User Priority Regeneration Table has an impact to the QoS 
>> classes since they are essentially mapped to the traffic classes.
>>
>> However, a subsequent paragraph in the same section says:
>>
>> "Under normal circumstances, user priority is not modified in transit 
>> through the relay function of a Bridge; however, network management 
>> can control how user priority is propagated. Table 7-1 provides the 
>> ability to map incoming user priority values on a per-Port basis. By 
>> default, the regenerated user priority is identical to the incoming 
>> user priority."
>>
>> From my reading of the specification I wasn't quite sure what the big 
>> value of the User Priority Regeneration Table actually is, given the 
>> fact that you ideally do not want to modify the user priority values 
>> anyway.
> 
> 
> One potential usage might be to remap priorities of traffic sent at an 
> exchange point (e.g. unless ISP A has an arrangement with ISP B, then 
> ISP B's high priority traffic will be remapped to "best efforts" at the 
> exchange point).

Sounds good but does it fit a per-user specific remapping policy?

> 
>> My previous understanding was wrong and hence I think that including 
>> the User-Priority-Table attribute to Accounting-Request messages does 
>> not make sense.
> 
> 
> OK.
> 
>> There is an indirect relationship. Mapping a high user priority value 
>> of an incoming frame to a low user priority value obviously impacts 
>> the QoS treatement.
> 
> 
> Yes.
> 
> 
> 

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: Sun, 02 Apr 2006 18:37:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Review of draft-ietf-radext-vlan-02.txt
Date: Sun, 02 Apr 2006 11:36:53 -0700

Let's see if we can come up with text changes to address the issues that 
we've discussed on this thread.

First off, it seems like we need to include information on what attributes 
(if any) are allowed in an Accounting-Request.  Since use in an 
Accounting-Request is not mentioned for any attributes, by default, I'd 
assume that none of the attributes are valid in an Accounting-Request, but I 
wanted to make sure this is the case.

Here is a potential rewrite of Section 2.4:

2.4.  User-Priority-Table

   Description

      [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map)
      user priority on frames received at a port.  This per-port
      configuration enables a bridge to cause the priority of received
      traffic at a port to be mapped to a particular priority.
      [IEEE-802.1D] clause 6.3.9 states:

         The ability to signal user priority in IEEE 802 LANs allows
         user priority to be carried with end-to-end significance across
         a Bridged Local Area Network.  This, coupled with a consistent
         approach to the mapping of user priority to traffic classes and
         of user priority to access_priority, allows consistent use of
         priority information, according to the capabilities of the
         Bridges and MACs in the transmission path...

         Under normal circumstances, user priority is not modified in
         transit through the relay function of a Bridge; however,
         network management can control how user priority is propagated.
         Table 7-1 provides the ability to map incoming user priority
         values on a per-Port basis. By default, the regenerated user
         priority is identical to the incoming user priority.

      This attribute represents the IEEE 802 prioritization that will be
      applied to packets arriving at this port.  There are eight
      possible user priorities, according to the [IEEE-802] standard.
      [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table
      as 8 values, each an integer in the range 0-7.  By default, no
      remapping occurs.  The management variables are described in
      clause 14.6.2.2.

      A single User-Priority-Table attribute MAY be included in an
      Access-Accept or CoA-Request packet; this attribute MUST NOT be
      sent within an Access-Request, Access-Challenge, Access-Reject,
      Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or
      CoA-NAK.  Since the regeneration table is only maintained by a
      bridge conforming to [IEEE-802.1D], this attribute should only be
      sent to a RADIUS client supporting that specification.

      The User-Priority-Table attribute is shown below.  The fields are
      transmitted from left to right:

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

   Type

      TBD

   Length

      10

   String

      The String field is 8 octets in length, and includes a table which
      maps the incoming priority (if it is set - the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.
      The values in each octet represent the regenerated priority of the
      packet.

      It is thus possible to either remap incoming priorities to more
      appropriate values; to honor the incoming priorities; or to
      override any incoming priorities, forcing them to all map to a
      single chosen priority.

      The [IEEE-8021.D] specification, Annex G, provides a useful
      description of traffic type - traffic class mappings.

--
to unsubscribe send a message 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, 02 Apr 2006 17:49:37 +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: Sun, 02 Apr 2006 10:48:29 -0700

>Section 14.6.2 also mentiones that the User Priority Regeneration Table
>is for a specific port. Hence, I guess you have to send one User
>Priority Regeneration Table for each port and the User-Priority-Table 
>attribute then has to appear more than once (and has to refer to the
>respective port) in the Access-Accept.

I'd assume that the User-Priority-Table attribute implicitly refers to the 
NAS-Port attribute included in the Access-Request.  I don't think it is 
appropriate for the RADIUS server to attempt to set the User-Priority-Table 
attribute for another port (since that port might not even be in use by a 
user within the RADIUS server's home realm).

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

Unless someone can describe why this would be useful, you're probably right.

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

A few paragraphs explaining the 802.1D model and how it would be applied 
definitely seems in order.

>I went throught the spec in more detail and I came to the following 
>(probably tentative) conclusion.
>
>Section 6.3.9 (Frame Priority) gave some additional information:
>
>"The ability to signal user priority in IEEE 802 LANs allows user priority 
>to be carried with end-to-end significance across a Bridged Local Area 
>Network. This, coupled with a consistent approach to the mapping of user 
>priority to traffic classes and of user priority to access_priority, allows 
>consistent use of priority information, according to the capabilities of 
>the Bridges and MACs in the transmission path."
>
>As such, the User Priority Regeneration Table has an impact to the QoS 
>classes since they are essentially mapped to the traffic classes.
>
>However, a subsequent paragraph in the same section says:
>
>"Under normal circumstances, user priority is not modified in transit 
>through the relay function of a Bridge; however, network management can 
>control how user priority is propagated. Table 7-1 provides the ability to 
>map incoming user priority values on a per-Port basis. By default, the 
>regenerated user priority is identical to the incoming user priority."
>
>From my reading of the specification I wasn't quite sure what the big value 
>of the User Priority Regeneration Table actually is, given the fact that 
>you ideally do not want to modify the user priority values anyway.

One potential usage might be to remap priorities of traffic sent at an 
exchange point (e.g. unless ISP A has an arrangement with ISP B, then ISP 
B's high priority traffic will be remapped to "best efforts" at the exchange 
point).

>My previous understanding was wrong and hence I think that including the 
>User-Priority-Table attribute to Accounting-Request messages does not make 
>sense.

OK.

>There is an indirect relationship. Mapping a high user priority value of an 
>incoming frame to a low user priority value obviously impacts the QoS 
>treatement.

Yes.

--
to unsubscribe send a message 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, 02 Apr 2006 10:41:50 +0000
Date: Sun, 02 Apr 2006 12:40:56 +0200
From: Hannes Tschofenig <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Review of draft-ietf-radext-vlan-02.txt

Hi Bernard,

thanks for your quick feedback. Please find some comments below:

Bernard Aboba wrote:
>> 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.

Section 14.6.2 also mentiones that the User Priority Regeneration Table
is for a specific port. Hence, I guess you have to send one User
Priority Regeneration Table for each port and the User-Priority-Table
attribute then has to appear more than once (and has to refer to the
respective port) in the Access-Accept.

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

I went throught the spec in more detail and I came to the following 
(probably tentative) conclusion.

Section 6.3.9 (Frame Priority) gave some additional information:

"
The ability to signal user priority in IEEE 802 LANs allows user 
priority to be carried with end-to-end significance across a Bridged 
Local Area Network. This, coupled with a consistent approach to the 
mapping of user priority to traffic classes and of user priority to 
access_priority, allows consistent use of priority information, 
according to the capabilities of the Bridges and MACs in the 
transmission path.
"

As such, the User Priority Regeneration Table has an impact to the QoS 
classes since they are essentially mapped to the traffic classes.

However, a subsequent paragraph in the same section says:

"
Under normal circumstances, user priority is not modified in transit 
through the relay function of a Bridge; however, network management can 
control how user priority is propagated. Table 7-1 provides the ability 
to map incoming user priority values on a per-Port basis. By default, 
the regenerated user priority is identical to the incoming user priority.
"

 From my reading of the specification I wasn't quite sure what the big 
value of the User Priority Regeneration Table actually is, given the 
fact that you ideally do not want to modify the user priority values 
anyway.

Maybe someone else knows the use cases better. I couldn't find it in the 
specification.

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

My previous understanding was wrong and hence I think that including the
User-Priority-Table attribute to Accounting-Request messages does not
make sense.

>> 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.
There is an indirect relationship. Mapping a high user priority value of 
an incoming frame to a low user priority value obviously impacts the QoS 
treatement.

>  I 
> agree that it would not make much sense to do regeneration if you didn't 
> have a QoS goal in mind, though.
Also my opinion.

> 
>> 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).
Yes.

> 
>> 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.
That's again my observation as well.

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