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

["Bari, Farooq" <farooq.bari@attws.com>]

I support Jari's idea of renaming the group RADEXT to AAAEXT - this I
believe will reflect the true nature of the work and will also help
allay any concerns.

Farooq

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Jari Arkko
Sent: Monday, December 15, 2003 2:55 PM
To: BLACK,CHUCK (HP-Roseville,ex1)
Cc: radiusext@ops.ietf.org
Subject: Re: Comments on draft-black-radius-lanedge-00.txt


BLACK,CHUCK (HP-Roseville,ex1) wrote:
> 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.

Yes. Thanks for your response.

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

Yes -- though I would probably name RADEXT to AAAEXT and avoid
unnecessary focus to RADIUS only. Not that the name defines what the
group will do, but...

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

I think its fine to document all the attributes relevant for LANs
together -- but you should then make a distinction of those attributes
that you are now introducing in this document, and those that you just
import from other documents. This would help those readers who know both
documents, would help IANA, and would make it clear what document is
normative wrt to a given attribute.

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

The definitions appear to have the same contents, given that you refer
to Diameter data type. I think the semantics are also the same. Perhaps
you should just state that this is like the NAS-Filter-Rule AVP -- and
maybe name it NAS-Filter-Rule-Radius or something like that to make it
obvious.

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

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