RE: Issue: Allowed Usage

["Avi Lior" <avi@bridgewatersystems.com>]

There is no reason to include even a flush in a disconnect request.

If you are successful in disconnect, then the flush will happen anyway.
If you are not successful in disconnecting then even if you included
flush nothing will happen.

Avi 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber 
> (gdweber)
> Sent: Wednesday, February 01, 2006 7:42 PM
> To: Bernard Aboba; radiusext@ops.ietf.org
> Subject: RE: Issue: Allowed Usage
> 
> 
> Also, the textual description of Ingress-Filters says that it 
> MUST NOT be included in Disconnect-Request messages (and some 
> other types of messages).  This is not reflected in the Table 
> of Attributes in Section 4 which may be confusing.  Would any 
> of these attributes be used in Disconnect-Request messages?  
> I'd guess not, except maybe a flush rule...  :)
> 
> Greg
> 
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Sunday, January 29, 2006 3:07 PM
> > To: radiusext@ops.ietf.org
> > Subject: Issue: Allowed Usage
> > 
> > Issue : Allowed Usage
> > Submitter names: Bernard Aboba
> > Submitter email address: aboba@internaut.com Date first submitted: 
> > January 29, 2006
> > Reference:
> > Document: IEEE 802-01
> > Comment type: 'T'echnical |
> > Priority: S
> > Section: Various
> > Rationale/Explanation of issue:
> > 
> > In Section 4, the Table of Attributes states the following:
> > 
> >       The following table provides a guide to which 
> attributes may be
> >       found in which kinds of packets, and in what quantity.
> > 
> >       Access- Access- Access- Access-   CoA-
> >       Request Accept  Reject  Challenge Req  #   Attribute
> >       0       0+      0       0         0+   TBD Egress-VLANID
> >       0       0-1     0       0         0-1  TBD Ingress-Filters
> >       0       0-1     0       0         0-1  TBD User-Priority-Table
> > 
> > The Egress-VLAN-Name attribute is not included in this 
> table, nor is 
> > it included in the IANA considerations section.
> > 
> > Section 2.1:
> > 
> >          Multiple Egress-VLANID attributes can be delivered in an
> >          authentication response; each attribute adds the specified 
> > VLAN
> >          to the list of allowed egress VLANs for the port.
> > 
> > This would appear to indicate that the Egress-VLAN-Name 
> attribute is 
> > allowed in Access-Challenge, Access-Reject and 
> Access-Accept packets.
> > Yet, the attribute table in Section 4 does not seem to permit 
> > inclusion in Reject or Challenge packets.
> > 
> > Section 2.3:
> > 
> >          Multiple Egress-VLAN-Name attributes can be delivered in an
> >          authentication response; each attribute adds the 
> named VLAN 
> > to
> >          the list of allowed egress VLANs for the port.
> > 
> > This would appear to indicate that the Egress-VLAN-Name 
> attribute is 
> > allowed in Access-Challenge, Access-Reject and 
> Access-Accept packets.
> > There is no entry in the Attribute Table to confirm this.
> > 
> > Section 2.4:
> > 
> > There is no material on permitted usage of the User-Priority-Table 
> > attribute.
> > 
> > 
> > 
> > --
> > 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: <http://psg.com/lists/radiusext/>
> > 
> 
> --
> 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: <http://psg.com/lists/radiusext/>
> 

--
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: <http://psg.com/lists/radiusext/>