Re: Comments on draft-ietf-radext-filter-04

["Alan DeKok" <aland@nitros9.org>]

  Additional comments, similar to Pasi's comments:

  Abstract: 

   This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS), equivalent to the
   Diameter NAS-Filter-Rule AVP described in RFC 4005.

  I'm not sure what "equivalent" means here.  Maybe "the RADIUS
counterpart to the Diameter AVP"?  The attributes aren't equivalent,
as their ID's and encapsulation methods are different.  But the intent
is that they carry the same data, in the same format.

> 1) Section 1.3: "It is recommended that an Error-Cause..." 
> Perhaps uppercase "RECOMMENDED" would be appropriate here?

  Or SHOULD?

  Also section 1.3:

   this situation does not result in session termination
   and the pre-existing configuration remains unchanged.  As a result,
   no accounting packets should be generated.

  ... for the CoA request.  The session may still generate accounting
packets as part of its ongoing process.

> 2) Section 2: "the individual filter rules SHOULD be determined by
> concatenating the contents of all NAS-Filter-Rule attributes, and then
> splitting individual filter rules with the the NUL octet (0x00) as a
> delimeter." I don't think "SHOULD" is correct here. How about just
> "the individual filter rules _are_ determined..."?

  Yes.

> 3) Section 4: The text about Diameter-to-RADIUS translation could be
> clearer (currently it only describes how the translation works for
> >253 octet rules, but not the <253 octet case). Suggested
> text (replacing 2nd paragraph):

  I would suggest re-using the text from the RADIUS encapsulation case
above:

      When translating Diameter NAS-Filter-Rule AVPs to RADIUS
      NAS-Filter-Rule attributes, the set of NAS-Filter-Rule
      attributes SHOULD be created by concatenating the individual
      filter rules, separated by a NUL (0x00) octet.  The resulting
      data should be split on 253 byte boundaries to obtain a set of
      NAS-Filter-Rule attributes.  When translating RADIUS
      NAS-Filter-Rule attributes to Diameter NAS-Filter-Rule AVPs, the
      individual Diameter NAS-Filter-Rule AVPs rules SHOULD be
      determined by concatenating the contents of all NAS-Filter-Rule
      attributes, and then splitting individual filter rules with the
      the NUL octet (0x00) as a delimeter.  Each rule is then encoded
      as a single Diameter NAS-Filter-Rule AVP.

  i.e. Take the last paragraph from section 2, and added a few phrases
about Diameter.

  That repetition should make it clear that the process for RADIUS
encapsulation is the same, independent of the source of the attributes.

  Also for section 3, I would add:

   Access- Access- Access- Access-   CoA-  Acct-
   Request Accept  Reject  Challenge Req   Req   #   Attribute
    0       0+      0       0        0+    0+   TBD  NAS-Filter-Rule [note1]

   Note1: NAS-Filter-Rule is precluded from appearing in a packet if a
   Filter-Id or NAS-Traffic-Rule attribute is present


  Alan DeKok.

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