RE: Review of draft-ietf-radext-vlan-02.txt

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Presumably until the expiration of Session-Timeout.

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

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



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>