Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 30 Apr 2006 23:15:06 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: Issue 190: Relationship of Tunnel and Egress-VLAN attributes Date: Sun, 30 Apr 2006 16:14:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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)" >To: "Bernard Aboba" , >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 30 Apr 2006 18:12:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 190: Relationship of Tunnel and Egress-VLAN attributes Date: Sun, 30 Apr 2006 11:12:36 -0700 Message-ID: Thread-Topic: Issue 190: Relationship of Tunnel and Egress-VLAN attributes Thread-Index: AcZrmydu+Zjka5heRyOX6xU43ONe7wA5kukA From: "Sanchez, Mauricio (ProCurve)" To: "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, April 29, 2006 7:42 AM > To: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 30 Apr 2006 17:43:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Sun, 30 Apr 2006 10:42:26 -0700 Message-ID: Thread-Topic: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZrHP+8G0mh/jGDRceo66bxZP0KdwAGVbGA From: "Sanchez, Mauricio (ProCurve)" To: "Bernard Aboba" , "Congdon, Paul T (ProCurve)" , Ok with me. MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, April 28, 2006 4:39 PM > To: Congdon, Paul T (ProCurve); radiusext@ops.ietf.org > 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)" > >To: > >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: owner-radiusext@ops.ietf.org > >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio > >(ProCurve) > > Sent: Thursday, April 27, 2006 5:44 PM > > To: radiusext@ops.ietf.org > > Subject: Vlan draft - relationhip of tunnel attributes=20 > and egress-xxx=20 > >attributes > > > > > > > > Relationship of tunnel attributes and egress-xxx attributes > > address: mauricio.sanchez@hp.com 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 > > mauricio.sanchez@hp.com > > -------------------------------------------- > > >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 29 Apr 2006 14:42:14 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Conclusion of WG last call on VLAN/Priority Document Date: Sat, 29 Apr 2006 07:41:45 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 29 Apr 2006 06:02:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Fri, 28 Apr 2006 23:02:12 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404C9348E@cacexc07.americas.cpqcorp.net> Thread-Topic: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZrHO8EhA8YAgRWS1ieHO0J1ZGDSAANXyfw From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , This sounds good to me=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Friday, April 28, 2006 4:39 PM > To: Congdon, Paul T (ProCurve); radiusext@ops.ietf.org > 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)" > >To: > >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: owner-radiusext@ops.ietf.org > >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio > >(ProCurve) > > Sent: Thursday, April 27, 2006 5:44 PM > > To: radiusext@ops.ietf.org > > Subject: Vlan draft - relationhip of tunnel attributes=20 > and egress-xxx=20 > >attributes > > > > > > > > Relationship of tunnel attributes and egress-xxx attributes > > address: mauricio.sanchez@hp.com 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 > > mauricio.sanchez@hp.com > > -------------------------------------------- > > >=20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 23:39:09 +0000 Message-ID: From: "Bernard Aboba" To: paul.congdon@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Fri, 28 Apr 2006 16:38:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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)" >To: >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: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio >(ProCurve) > Sent: Thursday, April 27, 2006 5:44 PM > To: radiusext@ops.ietf.org > Subject: Vlan draft - relationhip of tunnel attributes and >egress-xxx attributes > > > > Relationship of tunnel attributes and egress-xxx attributes > address: mauricio.sanchez@hp.com 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 > mauricio.sanchez@hp.com > -------------------------------------------- > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 21:22:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Fri, 28 Apr 2006 14:20:50 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404C93334@cacexc07.americas.cpqcorp.net> Thread-Topic: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZqXNrMvNEzlaf1SK2SPKQdiMKH7gAEltkwABpMNaAADEnOIA== From: "Congdon, Paul T (ProCurve)" To: "Sanchez, Mauricio (ProCurve)" Cc: 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: radiusext@ops.ietf.org > 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez,=20 > Mauricio (ProCurve) > Sent: Thursday, April 27, 2006 5:44 PM > To: radiusext@ops.ietf.org > 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: mauricio.sanchez@hp.com 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 > mauricio.sanchez@hp.com=20 > -------------------------------------------- =20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 16:52:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Fri, 28 Apr 2006 09:51:23 -0700 Message-ID: Thread-Topic: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZqXNrMvNEzlaf1SK2SPKQdiMKH7gAEltkwABpMNaA= From: "Sanchez, Mauricio (ProCurve)" To: "Congdon, Paul T (ProCurve)" Cc: 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Thursday, April 27, 2006 5:44 PM To: radiusext@ops.ietf.org Subject: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes =09 =09 Relationship of tunnel attributes and egress-xxx attributes=20 address: mauricio.sanchez@hp.com 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 mauricio.sanchez@hp.com=20 -------------------------------------------- =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 04:13:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66A7A.07F6ED2A" Subject: FW: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Thu, 27 Apr 2006 21:12:57 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404C92E9C@cacexc07.americas.cpqcorp.net> Thread-Topic: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZqXNrMvNEzlaf1SK2SPKQdiMKH7gAEltkwAAKwxOA= From: "Congdon, Paul T (ProCurve)" To: 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Thursday, April 27, 2006 5:44 PM To: radiusext@ops.ietf.org Subject: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes =09 =09 Relationship of tunnel attributes and egress-xxx attributes=20 address: mauricio.sanchez@hp.com 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 mauricio.sanchez@hp.com=20 -------------------------------------------- =20 ------_=_NextPart_001_01C66A7A.07F6ED2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vlan draft - relationhip of tunnel attributes and = egress-xxx attributes
 
some how the list got dropped... C= omments welcome.

 
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

Ooops... Here are the suggested changes I was = going to=20 make.   Word smithing expected... Replace the two = paragraphs=20 suggested with the following.
 
"The tunnel attributes used for VLAN assignment 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.   The Egress-VLANID configures only the=20 egress VLAN ID for either tagged or untagged packets.  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.  These=20 attributes can be used concurrently and MAY appear in the same = RADIUS=20 message.  To configure an untagged VLAN for both ingress and egress = the=20 tunnel attrubutes of [RFC3580] MUST be used."
 
Paul

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, = Mauricio=20 (ProCurve)
Sent: Thursday, April 27, 2006 5:44 = PM
To:=20 radiusext@ops.ietf.org
Subject: Vlan draft - relationhip of = tunnel=20 attributes and egress-xxx attributes

Relationship of tunnel = attributes and=20 egress-xxx attributes
address:=20 mauricio.sanchez@hp.com Date first submitted: 4/27/06
Reference: none
Document: draft-ietf-radext-vlan-04.txt
Comment type: T
Priority: S
Section: 2.1,=20 2.3
Rationale/Explanation of=20 issue:
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.  I=20 suggest formalizing the fact that they can be used concurrently and = providing=20 guidance on their interaction/relationship.

Requested change:

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

"Tunnel attributes, as = described in=20 [RFC2868] and [RFC3580], and Egress-VLANID both can be used to = configure the=20 egress  VLAN for untagged packets.  These attributes can be = used=20 concurrently and MAY appear in the same RADIUS message.  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

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


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:

"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.  These attributes can be = used=20 concurrently and MAY appear in the same RADIUS message.  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.

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


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

916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------  =20

------_=_NextPart_001_01C66A7A.07F6ED2A-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 02:55:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66A6F.299E7178" Subject: RE: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Thu, 27 Apr 2006 19:55:07 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404C92E7A@cacexc07.americas.cpqcorp.net> Thread-Topic: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZqXNrMvNEzlaf1SK2SPKQdiMKH7gAEi8fA From: "Congdon, Paul T (ProCurve)" To: "Sanchez, Mauricio (ProCurve)" , 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Thursday, April 27, 2006 5:44 PM To: radiusext@ops.ietf.org Subject: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes =09 =09 Relationship of tunnel attributes and egress-xxx attributes=20 address: mauricio.sanchez@hp.com 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 mauricio.sanchez@hp.com=20 -------------------------------------------- =20 ------_=_NextPart_001_01C66A6F.299E7178 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vlan draft - relationhip of tunnel attributes and = egress-xxx attributes
This sounds like the spirit.  I'd suggest = the=20 following changes.
 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, = Mauricio=20 (ProCurve)
Sent: Thursday, April 27, 2006 5:44 = PM
To:=20 radiusext@ops.ietf.org
Subject: Vlan draft - relationhip of = tunnel=20 attributes and egress-xxx attributes

Relationship of tunnel = attributes and=20 egress-xxx attributes
address:=20 mauricio.sanchez@hp.com Date first submitted: 4/27/06
Reference: none
Document: draft-ietf-radext-vlan-04.txt
Comment type: T
Priority: S
Section: 2.1,=20 2.3
Rationale/Explanation of=20 issue:
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.  I=20 suggest formalizing the fact that they can be used concurrently and = providing=20 guidance on their interaction/relationship.

Requested change:

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

"Tunnel attributes, as = described in=20 [RFC2868] and [RFC3580], and Egress-VLANID both can be used to = configure the=20 egress  VLAN for untagged packets.  These attributes can be = used=20 concurrently and MAY appear in the same RADIUS message.  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

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


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:

"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.  These attributes can be = used=20 concurrently and MAY appear in the same RADIUS message.  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.

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


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

916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------  =20

------_=_NextPart_001_01C66A6F.299E7178-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Apr 2006 00:44:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66A5C.DB8AC90B" Subject: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Date: Thu, 27 Apr 2006 17:44:06 -0700 Message-ID: Thread-Topic: Vlan draft - relationhip of tunnel attributes and egress-xxx attributes Thread-Index: AcZqXNrMvNEzlaf1SK2SPKQdiMKH7g== From: "Sanchez, Mauricio (ProCurve)" To: 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: mauricio.sanchez@hp.com 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 mauricio.sanchez@hp.com -------------------------------------------- =20 ------_=_NextPart_001_01C66A5C.DB8AC90B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vlan draft - relationhip of tunnel attributes and egress-xxx = attributes

Relationship of tunnel attributes = and egress-xxx attributes
address: mauricio.sanchez@hp.com = 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
mauricio.sanchez@hp.com
--------------------------------------------   =

------_=_NextPart_001_01C66A5C.DB8AC90B-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Apr 2006 19:45:31 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: Vlan draft - Usage mxture of "packet" and "frame" terms for Ethernet frames Date: Thu, 27 Apr 2006 12:45:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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)" >To: >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: mauricio.sanchez@hp.com >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 >mauricio.sanchez@hp.com >-------------------------------------------- > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Apr 2006 18:46:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66A2A.C25A4210" Subject: Vlan draft - Usage mxture of "packet" and "frame" terms for Ethernet frames Date: Thu, 27 Apr 2006 11:45:30 -0700 Message-ID: Thread-Topic: Vlan draft - Usage mxture of "packet" and "frame" terms for Ethernet frames Thread-Index: AcZqKsIbf5UyfUmASgiCCLGigttphA== From: "Sanchez, Mauricio (ProCurve)" To: 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: mauricio.sanchez@hp.com 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 mauricio.sanchez@hp.com -------------------------------------------- =20 ------_=_NextPart_001_01C66A2A.C25A4210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vlan draft - Usage mxture of "packet" and = "frame" terms for Ethernet frames

Usage mxture of = "packet" and "frame" terms for Ethernet frames = Submitter name: Mauricio Sanchez Submitter email address: = mauricio.sanchez@hp.com 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
mauricio.sanchez@hp.com
--------------------------------------------   =

------_=_NextPart_001_01C66A2A.C25A4210-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Apr 2006 12:49:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on draft-ietf-radext-filter-rules-00.txt Date: Wed, 26 Apr 2006 14:48:20 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFB80E@SEHAN021MB.tcad.telia.se> Thread-Topic: Comments on draft-ietf-radext-filter-rules-00.txt Thread-Index: AcY7+LFFc78Nt2Q0SkmqKiWwH619ZgsimRtw From: To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Apr 2006 05:37:17 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: REMINDER: RADEXT WG last call in progress on VLAN/Priority Attributes Document Date: Mon, 24 Apr 2006 22:36:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 (eap@frascone.com) in the format described on the RADEXT WG Issues List: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Apr 2006 04:56:01 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Issue 189: Attribute Semantics Date: Mon, 24 Apr 2006 21:55:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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: dnelson@enterasys.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Apr 2006 04:53:20 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Last look at RADIUS Digest Authentication Draft Date: Mon, 24 Apr 2006 21:52:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 21 Apr 2006 20:30:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Minutes or the RADEXT Session at IETF-65 Date: Fri, 21 Apr 2006 16:29:39 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021920A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Minutes or the RADEXT Session at IETF-65 Thread-Index: AcZlglAuUWLwjbSOSJWm3jNVJgoVwA== From: "Nelson, David" To: (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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 Apr 2006 22:59:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Thu, 20 Apr 2006 15:58:46 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404BCBCE7@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZj0EqpKWp6DwdkTQaQtENT/YLvPgA/ZX9Q From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, April 19, 2006 9:42 AM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 19:50:40 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-digest-auth-08.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-19111910.I-D@ietf.org> 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: <2006-4-19111910.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 19:50:32 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-digest-auth-08.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-19112630.I-D@ietf.org> 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: <2006-4-19112630.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 17:09:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Wed, 19 Apr 2006 13:09:24 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191EE@MABOSEVS2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZj0DMm0X1QaY70RJepgxB8r8M7CQAA2Ynw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 16:42:17 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Wed, 19 Apr 2006 09:41:56 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 16:15:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Wed, 19 Apr 2006 12:14:44 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191ED@MABOSEVS2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZjyW1++hIj7MXmSlWZpi+zXRanIQAAbNFQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Apr 2006 15:54:00 +0000 Message-ID: From: "Bernard Aboba" To: paul.congdon@hp.com, dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Wed, 19 Apr 2006 08:53:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Apr 2006 22:42:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: New Issue: RE: RADEXT WG last call on VLAN and Priority Document Date: Tue, 18 Apr 2006 18:41:51 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191EB@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Issue: RE: RADEXT WG last call on VLAN and Priority Document Thread-Index: AcZfTy8S8DV2oohdS1q8e/Rq1+Z5ewD6SipQ From: "Nelson, David" To: Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Apr 2006 22:22:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 18 Apr 2006 18:22:44 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191EA@MABOSEVS2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZiZIeDr3IVJSHRSr2jbC4SzkLFwAAnIMrwAAyZufAAAIhCUA== From: "Nelson, David" To: 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: 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". How does this text look? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Apr 2006 22:14:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 18 Apr 2006 15:12:37 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404B82BF7@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZiZIeDr3IVJSHRSr2jbC4SzkLFwAAnIMrwAAyZufA= From: "Congdon, Paul T (ProCurve)" To: "Nelson, David" , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, April 18, 2006 9:58 AM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Apr 2006 16:58:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 18 Apr 2006 12:58:11 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191E8@MABOSEVS2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZiZIeDr3IVJSHRSr2jbC4SzkLFwAAnIMrw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Apr 2006 21:30:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 17 Apr 2006 14:29:32 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404B82481@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZiZJrineBEMLNtQ/yCxaTOsVqq3AAASlOA From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , , >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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, April 17, 2006 2:19 PM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Apr 2006 21:19:03 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 17 Apr 2006 14:18:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Apr 2006 18:03:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 17 Apr 2006 14:02:33 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191DD@MABOSEVS2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZbCvPOlkLDO9wiT2uM8RtxJKr9aQHPZb4g From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 16 Apr 2006 15:32:57 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Cc: rdroms@cisco.com Bcc: Subject: Conclusion of RADEXT WG last call on draft-ietf-radiusext-delegated-prefix-00 Date: Sun, 16 Apr 2006 08:32:45 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 16 Apr 2006 15:18:08 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Issue 188: Delegated Prefix NITs Date: Sun, 16 Apr 2006 08:17:33 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Issue 188: Delegated Prefix NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 14 Apr 2006 17:31:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: 802.1X dependency Date: Fri, 14 Apr 2006 10:31:28 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404B478EE@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue: 802.1X dependency Thread-Index: AcZeVrEXgsjuKtI8RMOws3Axe7UttABkox+g From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , This looks good to me=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, April 12, 2006 10:29 AM > To: radiusext@ops.ietf.org > Subject: Issue: 802.1X dependency >=20 > Description of issue: 802.1X dependency > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 13 Apr 2006 23:08:13 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG last call on VLAN and Priority Document Date: Thu, 13 Apr 2006 16:07:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 13 Apr 2006 19:50:26 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-vlan-03.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-13145306.I-D@ietf.org> 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: <2006-4-13145306.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 13 Apr 2006 16:46:06 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 13 Apr 2006 09:45:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 13 Apr 2006 14:15:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 13 Apr 2006 10:15:18 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191D2@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZC/v/lfgJLjpoNSWm39oYf95M9XQAAlP4ABwDOI0A= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 12 Apr 2006 17:29:24 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Issue: 802.1X dependency Date: Wed, 12 Apr 2006 10:28:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Description of issue: 802.1X dependency Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Apr 2006 13:36:33 +0000 Message-ID: From: "Bernard Aboba" To: hannes.tschofenig@siemens.com, radiusext@ops.ietf.org Bcc: Subject: RE: AW: Use of VLAN attributes in Accounting-Requests Date: Tue, 11 Apr 2006 06:36:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Apr 2006 11:48:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: Use of VLAN attributes in Accounting-Requests Date: Tue, 11 Apr 2006 13:47:47 +0200 Message-ID: Thread-Topic: Use of VLAN attributes in Accounting-Requests Thread-Index: AcZdMjZAjYi3mOq4T6CaZDgQ/tdxaQAI001Q From: "Tschofenig, Hannes" To: "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Dienstag, 11. April 2006 08:35 > An: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Apr 2006 06:42:57 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: digest-auth surgery in Dallas Date: Mon, 10 Apr 2006 23:42:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Apr 2006 06:35:54 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Use of VLAN attributes in Accounting-Requests Date: Mon, 10 Apr 2006 23:35:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Apr 2006 12:49:39 +0000 Message-ID: <44379838.90509@gmx.net> Date: Sat, 08 Apr 2006 13:02:16 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Sanchez, Mauricio (ProCurve)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:Hannes.Tschofenig@gmx.net] >>Sent: Wednesday, April 05, 2006 1:07 AM >>To: Hannes Tschofenig >>Cc: Sanchez, Mauricio (ProCurve); Bernard Aboba; >>radiusext@ops.ietf.org >>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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 07 Apr 2006 23:13:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Fri, 7 Apr 2006 16:12:54 -0700 Message-ID: Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZYkEe/C1oouInaQOSJSjGGEc7CnwCCDbPg From: "Sanchez, Mauricio (ProCurve)" To: "Hannes Tschofenig" Cc: "Bernard Aboba" , 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:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, April 05, 2006 1:07 AM > To: Hannes Tschofenig > Cc: Sanchez, Mauricio (ProCurve); Bernard Aboba;=20 > radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 21:41:37 +0000 Message-ID: <44336D05.9020604@gmx.net> Date: Wed, 05 Apr 2006 09:08:53 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Sanchez, Mauricio (ProCurve)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 21:27:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Thu, 6 Apr 2006 00:27:29 +0300 Message-ID: Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZY7EytNCQZ6HHEQJiIdEixLtlv8AACw+EQ From: "Romascanu, Dan \(Dan\)" To: "Barney Wolff" Cc: "Nelson, David" , , "Carl Kalbfleisch" , =20 =20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 20:36:05 +0000 Message-ID: <44336D05.9020604@gmx.net> Date: Wed, 05 Apr 2006 09:08:53 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Sanchez, Mauricio (ProCurve)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 20:07:51 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 15:06:18 -0500 Message-ID: <7221140AD3DA7C4DB2CD49771243D8DDE2B261@nrmail01.netrake.net> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZY7CwNlzN8bKIXS4Ca04j62KO9XgAABnzQ From: "Carl Kalbfleisch" To: "Barney Wolff" , "Romascanu, Dan \(Dan\)" Cc: "Nelson, David" , , I think the model is the interface MIB which provides discontinuity per = interface. Carl > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Wednesday, April 05, 2006 3:05 PM > To: Romascanu, Dan (Dan) > Cc: Nelson, David; stefaan.de_cnodder@alcatel.be; Carl Kalbfleisch; > radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 20:06:30 +0000 Date: Wed, 5 Apr 2006 16:05:24 -0400 From: Barney Wolff To: "Romascanu, Dan (Dan)" Cc: "Nelson, David" , stefaan.de_cnodder@alcatel.be, Carl Kalbfleisch , radiusext@ops.ietf.org Subject: Re: looking for advise on RFC-2618 and 2620 Message-ID: <20060405200524.GA83302@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 19:13:51 +0000 Message-ID: <44337A95.80106@gmx.net> Date: Wed, 05 Apr 2006 10:06:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Hannes Tschofenig CC: "Sanchez, Mauricio (ProCurve)" , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:48:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 20:48:09 +0300 Message-ID: Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZY0/9dD6DFBFMeRzidtK5SZawahAAA9zfQ From: "Romascanu, Dan \(Dan\)" To: "Barney Wolff" , "Nelson, David" Cc: , "Carl Kalbfleisch" , =20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Wednesday, April 05, 2006 8:11 PM > To: Nelson, David > Cc: stefaan.de_cnodder@alcatel.be; Carl Kalbfleisch;=20 > Romascanu, Dan (Dan); radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:36:50 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 20:36:44 +0300 Message-ID: Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZYtj/qmzPUCN/cRn6ccwP8AgvosgAG00EgAAERkNAAAC7KkAAAKQ2A From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , , "Carl Kalbfleisch" Cc: , "Wijnen, Bert \(Bert\)" , "David Kessens" 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:dnelson@enterasys.com]=20 > Sent: Wednesday, April 05, 2006 8:33 PM > To: Romascanu, Dan (Dan); stefaan.de_cnodder@alcatel.be; Carl=20 > Kalbfleisch > Cc: radiusext@ops.ietf.org; 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:33:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 13:32:45 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191BA@MABOSEVS2.ets.enterasys.com> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZYtj/qmzPUCN/cRn6ccwP8AgvosgAG00EgAAERkNAAAC7KkA== From: "Nelson, David" To: "Romascanu, Dan \(Dan\)" , , "Carl Kalbfleisch" Cc: , "Wijnen, Bert \(Bert\)" , "David Kessens" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:27:38 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 20:27:27 +0300 Message-ID: Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZYtj/qmzPUCN/cRn6ccwP8AgvosgAG00EgAAERkNA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , , "Carl Kalbfleisch" Cc: , "Wijnen, Bert \(Bert\)" , "David Kessens" 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:dnelson@enterasys.com]=20 > Sent: Wednesday, April 05, 2006 8:01 PM > To: stefaan.de_cnodder@alcatel.be; Carl Kalbfleisch;=20 > Romascanu, Dan (Dan) > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:11:55 +0000 Date: Wed, 5 Apr 2006 13:11:28 -0400 From: Barney Wolff To: "Nelson, David" Cc: stefaan.de_cnodder@alcatel.be, Carl Kalbfleisch , "Dan Romascanu (E-mail)" , radiusext@ops.ietf.org Subject: Re: looking for advise on RFC-2618 and 2620 Message-ID: <20060405171128.GB40363@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 17:01:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Wed, 5 Apr 2006 13:00:39 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602191B9@MABOSEVS2.ets.enterasys.com> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZYtj/qmzPUCN/cRn6ccwP8AgvosgAG00Eg From: "Nelson, David" To: , "Carl Kalbfleisch" , "Dan Romascanu \(E-mail\)" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Apr 2006 13:37:39 +0000 Message-ID: <4433C7FD.4060001@alcatel.be> Date: Wed, 05 Apr 2006 15:37:01 +0200 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Carl Kalbfleisch , "Nelson, David" CC: radiusext@ops.ietf.org Subject: Re: looking for advise on RFC-2618 and 2620 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 23:58:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 4 Apr 2006 16:56:58 -0700 Message-ID: Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZWxGfc4N1n65KqTr2MegbjBUoH4wBfAxAA From: "Sanchez, Mauricio (ProCurve)" To: "Bernard Aboba" , Cc: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, April 02, 2006 7:14 PM > To: Hannes.Tschofenig@gmx.net > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 23:02:46 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: VLAN-03 strawman Date: Tue, 04 Apr 2006 16:02:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 17:50:12 +0000 Message-ID: <44326525.4030708@gmx.net> Date: Tue, 04 Apr 2006 14:23:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Congdon, Paul T (ProCurve)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 16:39:49 +0000 Message-ID: <443268ED.6010500@gmx.net> Date: Tue, 04 Apr 2006 14:39:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Bernard Aboba CC: paul.congdon@hp.com, radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 13:56:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 4 Apr 2006 06:55:56 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A7A183@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZX4M6zQcFOSL9TTK6Zb8cxRbwRvgADNwOw From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , Cc: 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:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, April 04, 2006 5:11 AM > To: Congdon, Paul T (ProCurve); Hannes.Tschofenig@gmx.net > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 12:27:30 +0000 Message-ID: From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net, paul.congdon@hp.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 04 Apr 2006 05:27:18 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Apr 2006 12:11:40 +0000 Message-ID: From: "Bernard Aboba" To: paul.congdon@hp.com, Hannes.Tschofenig@gmx.net Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Tue, 04 Apr 2006 05:10:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:46:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: VLAN-02 comments Date: Mon, 3 Apr 2006 09:45:50 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A36518@cacexc07.americas.cpqcorp.net> Thread-Topic: VLAN-02 comments Thread-Index: AcZXPhBnkz021BHhRpGHLyqca/KqlA== From: "Congdon, Paul T (ProCurve)" To: Cc: "Bernard Aboba" , "Sanchez, Mauricio (ProCurve)" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:37:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 3 Apr 2006 09:37:48 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A36503@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZXPKULXNQoKvN8RWi7wAMXEy7EOwAACgDQ From: "Congdon, Paul T (ProCurve)" To: "Hannes Tschofenig" Cc: "Bernard Aboba" , > > =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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:35:51 +0000 Message-ID: <44314ECE.1010907@gmx.net> Date: Mon, 03 Apr 2006 18:35:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Congdon, Paul T (ProCurve)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:13:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 3 Apr 2006 09:13:08 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A3649D@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZXOPFMb/qg59S7SyePfaNWmN2lRQAAEMnw From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , Cc: 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:bernard_aboba@hotmail.com]=20 > Sent: Monday, April 03, 2006 9:09 AM > To: Congdon, Paul T (ProCurve); Hannes.Tschofenig@gmx.net > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:09:16 +0000 Message-ID: From: "Bernard Aboba" To: paul.congdon@hp.com, Hannes.Tschofenig@gmx.net Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 03 Apr 2006 09:09:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 16:04:09 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Location draft issues raised today Date: Mon, 03 Apr 2006 09:03:56 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 15:57:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 3 Apr 2006 08:57:40 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A3645B@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZWkRhUIb1dqSpSQjWZfJhjYTeN4AApfsnw From: "Congdon, Paul T (ProCurve)" To: "Hannes Tschofenig" , "Bernard Aboba" Cc: =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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 15:53:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Mon, 3 Apr 2006 08:53:15 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404A36448@cacexc07.americas.cpqcorp.net> Thread-Topic: Review of draft-ietf-radext-vlan-02.txt Thread-Index: AcZWxGgaJpC5i0+3R3iXHt5t9xVHRgAcdVPg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , Cc: =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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Apr 2006 02:14:35 +0000 Message-ID: From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Review of draft-ietf-radext-vlan-02.txt Date: Sun, 02 Apr 2006 19:14:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 02 Apr 2006 20:08:20 +0000 Message-ID: <44302F04.1060001@gmx.net> Date: Sun, 02 Apr 2006 22:07:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 02 Apr 2006 20:08:13 +0000 Message-ID: <44302F00.9070809@gmx.net> Date: Sun, 02 Apr 2006 22:07:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, paul_congdon@hp.com Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 02 Apr 2006 18:37:09 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Review of draft-ietf-radext-vlan-02.txt Date: Sun, 02 Apr 2006 11:36:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 02 Apr 2006 17:49:37 +0000 Message-ID: From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net Cc: radiusext@ops.ietf.org, paul_congdon@hp.com Bcc: Subject: Re: Review of draft-ietf-radext-vlan-02.txt Date: Sun, 02 Apr 2006 10:48:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 02 Apr 2006 10:41:50 +0000 Message-ID: <442FAA38.2000402@gmx.net> Date: Sun, 02 Apr 2006 12:40:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, paul_congdon@hp.com Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: