[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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