RE: Comments on draft-black-radius-lanedge-00.txt

["BLACK,CHUCK (HP-Roseville,ex1)" <chuck.black@hp.com>]

From: Jari Arkko [mailto:jari.arkko@piuha.net] 

>  o  In general I support this type of a specification that would
>     define WLAN or LAN specific attributes for AAA. We need this.

Good, it seemed that there would be interest in this, and the intention
was to generate discussion and arrive at some sort of consensus.

>  o  The attributes should be done in a general fashion, in one
>    document, and be applicable for both RADIUS and Diameter.
>    With translation, if necessary, described in the document.

Would you consider that this RADIUSEXT WG is the appropriate
place for this discussion then, since many of the folks involved
with RADIUS are also involved with Diameter?

>  o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
>     between this attribute and the Filter-Id attribute from RFC 2865?
>     Do we need another one?

There is no fundamental difference between the current typical
usage of the Filter-Id attribute and the new IP-Filter-Name.
However, this is also true, based on RFC 3580, of the VLAN
attributes, which are using the Tunnel attributes to specify
VLAN information (see section 3.9 of RFC 3580 for Filter-Id
usage, and section 3.31 for Tunnel/VLAN usage).

The intent was to extract the common LAN edge attributes and
place them together.  At the risk, as you mention, of redundancy.
I'm not sure argument should prevail, so some discussion
on the matter will help to decide the issue.

>o  Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute
>     length may reduce the usefulness of this attribute. I think
>     Filter-Id may have to be sufficient where this is an issue.

This is unfortunate but true.

>     Also, it would be better to hightlight the relationship of
>     the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
>     Note that this AVP has a code 400 which means it is not directly
>     RADIUS compatible. But if the definitions are aligned otherwise
>     then translation should at least be possible.

This may be true.  The Diameter IPFilterRule was chosen because of its
immediate likeness to the layer 3 inclinations of the IP-Filter-Raw
attribute.  It seems like using the NAS-Filter-Rule AVP would be more
inclusive; is that a desired direction?  There may be other reasons
for using NAS-Filter-Rule of which I am unaware.

> ...

>  o  It may be worthwhile to think a little bit how to divide the work
>     into documents if we get to standardizing this. Maybe one draft
>     on general access attributes, another one on 802, and we already have
>     one one that clarifies the use of existing attributes in 802.1X (RFC
>     3580).

These are also good suggestions.  It would be useful to have a more
organized and intentional categorization of attributes into their
intended domains.

/chuck

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Monday, December 15, 2003 4:54 AM
To: radiusext@ops.ietf.org; chuck.black@hp.com
Subject: Comments on draft-black-radius-lanedge-00.txt



I have read

   http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

and have some questions and comments:

  o  In general I support this type of a specification that would
     define WLAN or LAN specific attributes for AAA. We need this.

  o  The attributes should be done in a general fashion, in one
     document, and be applicable for both RADIUS and Diameter.
     With translation, if necessary, described in the document.

  o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
     between this attribute and the Filter-Id attribute from RFC 2865?
     Do we need another one?

  o  Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute
     length may reduce the usefulness of this attribute. I think
     Filter-Id may have to be sufficient where this is an issue.
     Also, it would be better to hightlight the relationship of
     the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
     Note that this AVP has a code 400 which means it is not directly
     RADIUS compatible. But if the definitions are aligned otherwise
     then translation should at least be possible.

  o  The Bandwidth-*-* attributes: I like these attributes. This seems
     like a general set of attributes which may even be used outside LANs.

  o  It may be worthwhile to think a little bit how to divide the work
     into documents if we get to standardizing this. Maybe one draft
     on general access attributes, another one on 802, and we already have
     one one that clarifies the use of existing attributes in 802.1X (RFC
     3580).

--Jari

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