Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Date: Fri, 29 Sep 2006 18:56:50 -0400

On Fri, Sep 29, 2006 at 01:30:12PM -0700, Bernard Aboba wrote:
> How about this?
> 
>   Tag
> 
>      The Tag field is used to identify the filter rule that is
>      represented; the length of the Tag field is one octet and it MUST
>      always be present.  The Tag field value MUST be in the range
>      0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of
>      0x00 are ignored upon receipt.
> 
>      Where a single filter rule is less than or equal to 252 octets in
>      length, it MUST be encoded with a tag value of '0' (0x30) and MUST
>      NOT be split between multiple NAS-Filter-Rule attributes.  Where a
>      single filter rule is split into multiple NAS-Filter-Rule
>      attributes, the attributes SHOULD be sent consecutively, without
>      intervening attributes with another Tag field value.  On receipt,
>      attributes with a Tag value of '0' (0x30) MUST NOT be concatenated
>      to form a single filter rule.
> 
>      Where a single filter rule exceeds 252 octets in length, the rule
>      MUST be encoded across multiple NAS-Filter-Rule attributes, each
>      with the same Tag value which MUST NOT be '0' (0x30).  Tag values
>      MUST be unique for each filter rule present in a RADIUS packet
>      with the exception of a Tag value of '0' (0x30), which may be used
>      in multiple attributes, each describing a single filter rule.

I hate to be stubborn, but unless it says "attributes MUST be sent
consecutively" the receiver cannot count on it, so the SHOULD is
useless.  Can anybody think of a reason for a sender to interleave
parts of attributes, other than actual malice?

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Sep 2006 21:03:40 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: RADIUS attribute extension formats: Do we understand the proposals? 
cc: [email-masked]
Date: Fri, 29 Sep 2006 16:56:47 -0400
Message-Id: <[email-masked]>

> Here is the attribute format, that I am proposing:

  I have no objection to this format.  It would appear to satisfy all
present requirements.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 20:30:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Fri, 29 Sep 2006 13:30:12 -0700

How about this?

   Tag

      The Tag field is used to identify the filter rule that is
      represented; the length of the Tag field is one octet and it MUST
      always be present.  The Tag field value MUST be in the range
      0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of
      0x00 are ignored upon receipt.

      Where a single filter rule is less than or equal to 252 octets in
      length, it MUST be encoded with a tag value of '0' (0x30) and MUST
      NOT be split between multiple NAS-Filter-Rule attributes.  Where a
      single filter rule is split into multiple NAS-Filter-Rule
      attributes, the attributes SHOULD be sent consecutively, without
      intervening attributes with another Tag field value.  On receipt,
      attributes with a Tag value of '0' (0x30) MUST NOT be concatenated
      to form a single filter rule.

      Where a single filter rule exceeds 252 octets in length, the rule
      MUST be encoded across multiple NAS-Filter-Rule attributes, each
      with the same Tag value which MUST NOT be '0' (0x30).  Tag values
      MUST be unique for each filter rule present in a RADIUS packet
      with the exception of a Tag value of '0' (0x30), which may be used
      in multiple attributes, each describing a single filter rule.

>From: Barney Wolff <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: Proposed Resolution to Issue 198: Attribute 
>Concatenation/Splitting
>Date: Fri, 29 Sep 2006 14:57:30 -0400
>
>On Thu, Sep 28, 2006 at 11:27:23PM -0700, Bernard Aboba wrote:
> >   Tag
> >
> >      The Tag field is one octet, and MUST always be present.  It is
> >      used to identify the filter rule that is represented.  Where a
> >      single filter rule exceeds 253 octets in length, the rule MUST be
> >      encoded across multiple NAS-Filter-Rule attributes, each with the
> >      same Tag value; Tag values MUST be unique for each filter rule
> >      present in a RADIUS packet with the exception of a Tag value of
> >      '0' (0x30).  The value of '0' (0x30) in the Tag field indicates
> >      that the attribute contains a filter rule that does not exceed 253
> >      octets in length; as a result attributes with a Tag value of 0x30
> >      MUST NOT be concatenated, and one or more Filter-Rule attributes
> >      with a tag value of 0x30 may be included in a single RADIUS
> >      packet, each describing a single filter rule.
>
>May I suggest that NAS-Filter-Rule attributes with different tag values
>MUST NOT appear between the segments into which a long rule is split?
>There is no benefit to the sender to allowing anything else, and
>considerable nuisance to the receiver.
>
>Also, I suggest that a rule which is not split MUST have tag value '0'.
>Again, there is no value to the sender for anything else, and this way
>the receiver can know whether a rule is going to be extended.  Perhaps
>the language implying that a rule <252 octets MUST NOT be split should
>be made more explicit, too.
>
>As an aside, it is a general misfeature of RADIUS that senders are
>allowed to do things, such as random ordering of attributes, that have
>little value for the sender but cause hardship for the receiver.  We are
>all so used to this nuisance that we hardly perceive it as such.
>
>--
>Barney Wolff         I never met a computer I didn't like.
>
>--
>to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 20:22:12 +0000
Subject: RE: RADIUS attribute extension formats:  Do we understand the  proposals?
Date: Fri, 29 Sep 2006 16:20:49 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Here is the attribute format, that I am proposing:

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value
   +---------------+---------------

   Type 26 for Vendor-Specific.

   Length >=3D 10

   Vendor-Id

   The high-order octet is zero (0) and the low-order 3 octets are zeros
   (0)s representing an extended IETF RADIUS attribute.

   Extended-Type

   One (1) Octet.  Up-to-date values of the RADIUS Extended-Type field
   are specified in the most recent "Assigned Numbers" IANA [5] .
   Values XXXX-YYYY are reserved.

   Length >=3D 4.  The length of the Extended-Type, Length, =
Framentation,
   Tag fields and the length of the Value field

   Fragementation (F):

   When set(1) the attribute is fragmented.  When clear (0), the
   attribute is not fragmented.  When the value portion of an extended
   attribute exceeds 246 octets the value is fragmented over one or more
   extended attribute.  In this case the Fragmentation Flag is set on
   the attribute(s) that contain the fragmentated value.

   Tag

   The Tag field is 7-bits and MUST always be present.  It is used to
   group extended attributes.  Attributes with the same non-zero value

   belong to the same group.  A tag value of zero(0) indicates that the
   attribute is not grouped.  A tag value of all-ones (0x7F) is
   reserved.

   Value

   One or more octets.

Here are some examples:

   Consider an attribute called Foo of type String.  Foo is allocated an
   Extended-Type by IANA of 10.  The following figure shows the encoding
   of Foo(0,10) =3D "Hello":

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (0)       |    (H)        |     (e)       |     (l)       |
   +---------------+---------------+-------------------------------+
   |     (l)       |    (o)        |
   +---------------+---------------+

   The next figure shows the encoding of Foo when the length of Foo is
   251 octets.  Foo(0,10) =3D "Hello W....end.".  In this case the value
   is fragmented over two attributes.  The first 246 octets are included
   in the first fragment and the remaing 5 octets appear in the second
   attributes which has the Framentation bit set to 1.

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               |(6 + 249 =3D 255)|                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        |(3 + 246 =3D 249)|
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (0)       |    (H)        |     (e)       |     (l)       |
   +---------------+---------------+-------------------------------+
   |     (l)       |    (o)        |               |     (W)       |
   +---------------+---------------+---------------+---------------+
   ................
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |1|   (0)       |    ( )        |     (e)       |     (n)       |
   +---------------+---------------+-------------------------------+
   |     (d)       |    (.)        |
   +---------------+---------------+

   Next consider the following structure:

     struct
       Integer a;
       String  b;
       Integer c;
     endStruct

   Element a is assigned and extended type of 20.  Element b is assigned
   an extended type of 25 and element c is assigned an exteded type of
   27.  The following figure illustrates the coding where a(0,20) =3D
   0xDEADDEAD, b(0,25) =3D "He.....The end." and is of length 251 =
octets;
   and c(0,27) =3D 0x12345678.  The attributes are grouped together with
   TAG=3D42.

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               |(6 + 7 =3D 13)   |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (20)        |(3 + 4 =3D 7)    |
   +-+-------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (42)      |    (0xde)     |     (0xad)    |     (0xde)    |
   +-+-------------+---------------+-------------------------------+
   |     (0xad)    | Type(26)      |  Length       | Vendor-Id(0)  |
   |               |               | (6 + 249 =3D 255|               |
   +---------------+---------------+---------------+---------------+
   | Vendor-Id (0)                                 | Extended-Type |
   |                                               |  (25)         |
   +---------------+-+-------------+---------------+---------------+
   | Length        |F| TAG         | Value         |  Value        |
   | (3+246) =3D 249 |0| (42)        |  (H)          |  (e)          |
   +---------------+-+-------------+---------------+---------------+

   ...........
   +---------------+---------------+---------------+---------------+
   | Value         | Value         | Value         |  Value        |
   | (.)           | (T)           | (h)           |  (e)          |
   +---------------+---------------+---------------+---------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (25)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |1|   (42)      |    ( )        |     (e)       |     (n)       |
   +---------------+---------------+---------------+---------------+
   |     (d)       |    (.)        |  Type (26)    | Length        |
   |               |               |               | (6+7 =3D 13)    |
   +---------------+---------------+---------------+---------------+
   | Vendor-Id (0)                                                 |
   |                                                               |
   +---------------+---------------+-+-------------+---------------+
   |Extended-Type  |  Length       |F|  TAG        |   Value       |
   |    (27)       |  (3+4 =3D 7)    |0|  (42)       |   (0x12)      |
   +---------------+---------------+-+-------------+---------------+
   |  Value        |  Value        |   Value       |
   |  (0x34)       |  (0x56)       |   (0x78)      |
   +---------------+---------------+---------------+

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 2:48 AM
> To: [email-masked]
> Subject: Proposed Resolution to Issue 202: Diameter-RADIUS=20
> gateway behavior not spec'd
>=20
> The text of Issue 202 is enclosed below.
>=20
> The proposed resolution is as follows:
>=20
> In Section 4, Change:
>=20
> "Note that since a Diameter AVP can be larger than the maximum RADIUS
>    packet size (4096), translation from Diameter to RADIUS may not be
>    possible in all cases."
>=20
> To:
>=20
> "Note that a translated Diameter message can be larger than=20
> the maximum RADIUS packet size (4096).  Where a=20
> Diameter/RADIUS gateway receives a Diameter message=20
> containing a NAS-Filter-Rule AVP that is too large to fit=20
> into a RADIUS packet, the Diameter/RADIUS gateway will=20
> respond to the originating Diameter peer with the=20
> DIAMETER_INVALID_AVP_LENGTH error (5014), and with a=20
> Failed-AVP AVP containing the NAS-Filter-Rule AVP.
> Since repairing the error will probably require re-working=20
> the filter rules, the originating peer should treat the=20
> combination of a DIAMETER_INVALID_AVP_LENGTH error and a=20
> Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error."
>=20
>=20
> ------------------------
> Description of issue: Diameter-RADIUS gateway behavior not=20
> completely specified Submitter name: Glen Zorn Submitter=20
> email address: [email-masked] Date first submitted: 26 Aug 06
> Document: draft-ietf-radext-filter-01.txt Comment type: T
> Priority: 1
> Section: 4
> Rationale/Explanation of issue:
>=20
> The last sentence of section 4 says
> "Note that since a Diameter AVP can be larger than the=20
> maximum RADIUS packet size (4096), translation from Diameter=20
> to RADIUS may not be possible in all cases."  While this is=20
> true, the behavior of the Diameter-RADIUS gateway in this=20
> case is left unspecified.  Is the response forwarded back=20
> toward the requests' originator without the untranslatable=20
> AVPs?  In the case of an Access-Accept message, Section
> 1.2 says "If a NAS conforming to this specification receives=20
> an Access-Accept packet containing a NAS-Filter-Rule=20
> attribute which it cannot apply, it MUST act as though it had=20
> received an Access-Reject.", it might be reasonable for the=20
> gateway to translate the Access-Accept into an Access-Reject,=20
> since an attribute that is missing because untranslatable can=20
> obviously not be applied.  In the case of a CoA message with=20
> an untranslatable attribute, should the message be translated=20
> into a Disconnect-Request or just discarded?  Or in both=20
> cases, should the gateway respond to the=20
> originating/responding Diameter peer with an appropriate=20
> error (e.g., DIAMETER_INVALID_AVP_LENGTH) and let it figure=20
> out the next step?  If so, it still seems that the peers=20
> behavior must be specified.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 20:16:34 +0000
Subject: RE: Proposed Resolution to Issue 202:  Diameter-RADIUS gateway behavior not spec'd
Date: Fri, 29 Sep 2006 16:16:17 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Here is the attribute format, that I am proposing:

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value
   +---------------+---------------

   Type 26 for Vendor-Specific.

   Length >=3D 10

   Vendor-Id

   The high-order octet is zero (0) and the low-order 3 octets are zeros
   (0)s representing an extended IETF RADIUS attribute.

   Extended-Type

   One (1) Octet.  Up-to-date values of the RADIUS Extended-Type field
   are specified in the most recent "Assigned Numbers" IANA [5] .
   Values XXXX-YYYY are reserved.

   Length >=3D 4.  The length of the Extended-Type, Length, =
Framentation,
   Tag fields and the length of the Value field

   Fragementation (F):

   When set(1) the attribute is fragmented.  When clear (0), the
   attribute is not fragmented.  When the value portion of an extended
   attribute exceeds 246 octets the value is fragmented over one or more
   extended attribute.  In this case the Fragmentation Flag is set on
   the attribute(s) that contain the fragmentated value.

   Tag

   The Tag field is 7-bits and MUST always be present.  It is used to
   group extended attributes.  Attributes with the same non-zero value

   belong to the same group.  A tag value of zero(0) indicates that the
   attribute is not grouped.  A tag value of all-ones (0x7F) is
   reserved.

   Value

   One or more octets.

Here are some examples:

   Consider an attribute called Foo of type String.  Foo is allocated an
   Extended-Type by IANA of 10.  The following figure shows the encoding
   of Foo(0,10) =3D "Hello":

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (0)       |    (H)        |     (e)       |     (l)       |
   +---------------+---------------+-------------------------------+
   |     (l)       |    (o)        |
   +---------------+---------------+

   The next figure shows the encoding of Foo when the length of Foo is
   251 octets.  Foo(0,10) =3D "Hello W....end.".  In this case the value
   is fragmented over two attributes.  The first 246 octets are included
   in the first fragment and the remaing 5 octets appear in the second
   attributes which has the Framentation bit set to 1.

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               |(6 + 249 =3D 255)|                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        |(3 + 246 =3D 249)|
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (0)       |    (H)        |     (e)       |     (l)       |
   +---------------+---------------+-------------------------------+
   |     (l)       |    (o)        |               |     (W)       |
   +---------------+---------------+---------------+---------------+
   ................
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (10)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |1|   (0)       |    ( )        |     (e)       |     (n)       |
   +---------------+---------------+-------------------------------+
   |     (d)       |    (.)        |
   +---------------+---------------+

   Next consider the following structure:

     struct
       Integer a;
       String  b;
       Integer c;
     endStruct

   Element a is assigned and extended type of 20.  Element b is assigned
   an extended type of 25 and element c is assigned an exteded type of
   27.  The following figure illustrates the coding where a(0,20) =3D
   0xDEADDEAD, b(0,25) =3D "He.....The end." and is of length 251 =
octets;
   and c(0,27) =3D 0x12345678.  The attributes are grouped together with
   TAG=3D42.

   +---------------------------------------------------------------+
   |                    1                   2                   3  |
   |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   +---------------+---------------+-------------------------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               |(6 + 7 =3D 13)   |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (20)        |(3 + 4 =3D 7)    |
   +-+-------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |0|   (42)      |    (0xde)     |     (0xad)    |     (0xde)    |
   +-+-------------+---------------+-------------------------------+
   |     (0xad)    | Type(26)      |  Length       | Vendor-Id(0)  |
   |               |               | (6 + 249 =3D 255|               |
   +---------------+---------------+---------------+---------------+
   | Vendor-Id (0)                                 | Extended-Type |
   |                                               |  (25)         |
   +---------------+-+-------------+---------------+---------------+
   | Length        |F| TAG         | Value         |  Value        |
   | (3+246) =3D 249 |0| (42)        |  (H)          |  (e)          |
   +---------------+-+-------------+---------------+---------------+

   ...........
   +---------------+---------------+---------------+---------------+
   | Value         | Value         | Value         |  Value        |
   | (.)           | (T)           | (h)           |  (e)          |
   +---------------+---------------+---------------+---------------+
   |   Type (26)   |  Length       |      Vendor-Id (0)            |
   |               | (6+8 =3D 14)    |                               |
   +---------------+---------------+-------------------------------+
   |          Vendor-Id(0)         | Extended-Type |  Length       |
   |                               |   (25)        | (3 + 5 =3D 8)   |
   +---------------+---------------+---------------+---------------+
   |F|   TAG       |   Value       |               |               |
   |1|   (42)      |    ( )        |     (e)       |     (n)       |
   +---------------+---------------+---------------+---------------+
   |     (d)       |    (.)        |  Type (26)    | Length        |
   |               |               |               | (6+7 =3D 13)    |
   +---------------+---------------+---------------+---------------+
   | Vendor-Id (0)                                                 |
   |                                                               |
   +---------------+---------------+-+-------------+---------------+
   |Extended-Type  |  Length       |F|  TAG        |   Value       |
   |    (27)       |  (3+4 =3D 7)    |0|  (42)       |   (0x12)      |
   +---------------+---------------+-+-------------+---------------+
   |  Value        |  Value        |   Value       |
   |  (0x34)       |  (0x56)       |   (0x78)      |
   +---------------+---------------+---------------+

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 2:48 AM
> To: [email-masked]
> Subject: Proposed Resolution to Issue 202: Diameter-RADIUS=20
> gateway behavior not spec'd
>=20
> The text of Issue 202 is enclosed below.
>=20
> The proposed resolution is as follows:
>=20
> In Section 4, Change:
>=20
> "Note that since a Diameter AVP can be larger than the maximum RADIUS
>    packet size (4096), translation from Diameter to RADIUS may not be
>    possible in all cases."
>=20
> To:
>=20
> "Note that a translated Diameter message can be larger than=20
> the maximum RADIUS packet size (4096).  Where a=20
> Diameter/RADIUS gateway receives a Diameter message=20
> containing a NAS-Filter-Rule AVP that is too large to fit=20
> into a RADIUS packet, the Diameter/RADIUS gateway will=20
> respond to the originating Diameter peer with the=20
> DIAMETER_INVALID_AVP_LENGTH error (5014), and with a=20
> Failed-AVP AVP containing the NAS-Filter-Rule AVP.
> Since repairing the error will probably require re-working=20
> the filter rules, the originating peer should treat the=20
> combination of a DIAMETER_INVALID_AVP_LENGTH error and a=20
> Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error."
>=20
>=20
> ------------------------
> Description of issue: Diameter-RADIUS gateway behavior not=20
> completely specified Submitter name: Glen Zorn Submitter=20
> email address: [email-masked] Date first submitted: 26 Aug 06
> Document: draft-ietf-radext-filter-01.txt Comment type: T
> Priority: 1
> Section: 4
> Rationale/Explanation of issue:
>=20
> The last sentence of section 4 says
> "Note that since a Diameter AVP can be larger than the=20
> maximum RADIUS packet size (4096), translation from Diameter=20
> to RADIUS may not be possible in all cases."  While this is=20
> true, the behavior of the Diameter-RADIUS gateway in this=20
> case is left unspecified.  Is the response forwarded back=20
> toward the requests' originator without the untranslatable=20
> AVPs?  In the case of an Access-Accept message, Section
> 1.2 says "If a NAS conforming to this specification receives=20
> an Access-Accept packet containing a NAS-Filter-Rule=20
> attribute which it cannot apply, it MUST act as though it had=20
> received an Access-Reject.", it might be reasonable for the=20
> gateway to translate the Access-Accept into an Access-Reject,=20
> since an attribute that is missing because untranslatable can=20
> obviously not be applied.  In the case of a CoA message with=20
> an untranslatable attribute, should the message be translated=20
> into a Disconnect-Request or just discarded?  Or in both=20
> cases, should the gateway respond to the=20
> originating/responding Diameter peer with an appropriate=20
> error (e.g., DIAMETER_INVALID_AVP_LENGTH) and let it figure=20
> out the next step?  If so, it still seems that the peers=20
> behavior must be specified.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 20:10:32 +0000
Subject: RE: RADIUS attribute extension formats:  Do we understand the  proposals?
Date: Fri, 29 Sep 2006 16:10:02 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I have just finished updating my original draft.

It looks like option 1.

Except that I have the most-significant bit of the TAG field is a
fragmentation flag.

When the bit is set it indicates that the attribute is a fragment of the
previous attribute.

When clear, the attribute is not a fragment.

I am waiting for my co-authors to review and will post then.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 3:08 AM
> To: [email-masked]
> Subject: RADIUS attribute extension formats: Do we understand=20
> the proposals?
>=20
> In previous mailing list discussion, we have discussed two=20
> major proposals for RADIUS attribute extension.  This message=20
> attempts to summarize the two proposals. =20
> Additions/corrections/comments welcome.
>=20
>=20
> 1. Glen + David's proposal:
>=20
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |  Length       |            Vendor-Id
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>           Vendor-Id (cont)           | Extended type |    Length2    |
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      Tag      |     Data...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>=20
>   Type
>=20
>      26 for Vendor-Specific.
>=20
>   Length
>=20
>      >=3D 7
>=20
>   Vendor-Id
>=20
>      0 (for Extended Attributes)
>=20
>   Extended Type
>=20
>      0:       Reserved
>      1-250:   Allocated by IANA
>      250-255: Reserved
>=20
>   Length2
>=20
>      >=3D0
>=20
>      Multiple subattributes MAY be encoded within a single Extended
>      Attribute, although they do not have to be.
>=20
>       Tag
>=20
>       The Tag field is always present.  Values include:
>=20
>          0:        Not Used (i.e. attribute is untagged)
>          1-255:    Tag value used to aggregate attributes into groups
>=20
> The value of the Tag field MAY be limited to printable ASCII=20
> values, for ease of human entry and interpretation.
>=20
> 2. Alan DeKok's proposal:
>=20
>=20
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |    Length     |            Extended-Type      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Value...
>     +-+-+-+-+-+-+-+-+
>=20
>     Type
>=20
>        TBD  (not 26)
>=20
>     Length
>=20
>        >=3D 4
>=20
>     Extended-Type
>=20
>        Two octets.
>=20
>        0:  Concatenation
>       1-255:  Reserved
>       255-65530: Allocated by IANA
>       65531-65535:  Reserved
>=20
>     Value
>=20
>        0-251 octets (Length - 4).
>=20
>     Only a single RADIUS Extended-Type attribute may be=20
> included within
>     a RADIUS attribute of Type TBD.   Where the value of the=20
> Extended-Type
>     field is zero (0), this indicates that the content of the=20
> value field is to
>     be concatenated with the contents of the value field in=20
> the previous
>     attribute of Type TBD.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 18:58:59 +0000
Date: Fri, 29 Sep 2006 14:57:30 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

On Thu, Sep 28, 2006 at 11:27:23PM -0700, Bernard Aboba wrote:
>   Tag
> 
>      The Tag field is one octet, and MUST always be present.  It is
>      used to identify the filter rule that is represented.  Where a
>      single filter rule exceeds 253 octets in length, the rule MUST be
>      encoded across multiple NAS-Filter-Rule attributes, each with the
>      same Tag value; Tag values MUST be unique for each filter rule
>      present in a RADIUS packet with the exception of a Tag value of
>      '0' (0x30).  The value of '0' (0x30) in the Tag field indicates
>      that the attribute contains a filter rule that does not exceed 253
>      octets in length; as a result attributes with a Tag value of 0x30
>      MUST NOT be concatenated, and one or more Filter-Rule attributes
>      with a tag value of 0x30 may be included in a single RADIUS
>      packet, each describing a single filter rule.

May I suggest that NAS-Filter-Rule attributes with different tag values
MUST NOT appear between the segments into which a long rule is split?
There is no benefit to the sender to allowing anything else, and
considerable nuisance to the receiver.

Also, I suggest that a rule which is not split MUST have tag value '0'.
Again, there is no value to the sender for anything else, and this way
the receiver can know whether a rule is going to be extended.  Perhaps
the language implying that a rule <252 octets MUST NOT be split should
be made more explicit, too.

As an aside, it is a general misfeature of RADIUS that senders are
allowed to do things, such as random ordering of attributes, that have
little value for the sender but cause hardship for the receiver.  We are
all so used to this nuisance that we hardly perceive it as such.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Sep 2006 17:12:20 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: RADIUS attribute extension formats: Do we understand the proposals? 
cc: [email-masked]
Date: Fri, 29 Sep 2006 13:05:35 -0400
Message-Id: <[email-masked]>

> In previous mailing list discussion, we have discussed two major proposals 
> for RADIUS attribute extension.  This message attempts to summarize the two 
> proposals.  Additions/corrections/comments welcome.
> 
> 
> 1. Glen + David's proposal:

  I have no objections to this proposal.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Sep 2006 17:10:28 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting 
cc: [email-masked]
Date: Fri, 29 Sep 2006 13:03:25 -0400
Message-Id: <[email-masked]>

  Nit:

> Where a
>       single filter rule exceeds 253 octets in length, the rule MUST be

  Since the Tag field takes one octet, the above text should be '252 octets'.

>       encoded across multiple NAS-Filter-Rule attributes, each with the
>       same Tag value; Tag values MUST be unique for each filter rule
>       present in a RADIUS packet with the exception of a Tag value of
>       '0' (0x30).  The value of '0' (0x30) in the Tag field indicates
>       that the attribute contains a filter rule that does not exceed 253

  Same here.  The NAS-Filter-Rule attribute can hold 253 octets, the
filter rule encapsulated in that attribute can be only 252 octets per
attribute.

  It may also be worth re-iterating the tag requirements from Section
3 of RFC 2882, "The byte value must be in the range 01-3F hex"

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 15:34:42 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Fri, 29 Sep 2006 08:34:11 -0700

OK.  Suggest changing this to:

"A robust implementation SHOULD support the field as undistinguished 
octets."

>From: <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>Subject: RE: Proposed Resolution to Issue 198: Attribute 
>Concatenation/Splitting
>Date: Fri, 29 Sep 2006 12:50:04 +0300
>
>Bernard Aboba wrote:
>
> > The text of Issue 198 is enclosed below.  The proposed
> > resolution is as follows:
>
>Works for me (as would many of the other alternatives).
>
>One minor nit:
>
> > The String field is one or more octets.  It contains filter rules in
> > the IPFilterRule syntax defined in [RFC3588] Section 4.3.  [RFC3629]
> > UTF-8 encoded 10646 characters are RECOMMENDED, but a robust
> > implementation SHOULD support the field as undistinguished octets.
>
>If it follows the IPFilterRule syntax, it never contains any characters
>not part of US-ASCII, so mentioning UTF-8 is sort of redundant...
>
>Best regards,
>Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 09:50:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Fri, 29 Sep 2006 12:50:04 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba wrote:

> The text of Issue 198 is enclosed below.  The proposed=20
> resolution is as follows:

Works for me (as would many of the other alternatives).

One minor nit:

> The String field is one or more octets.  It contains filter rules in
> the IPFilterRule syntax defined in [RFC3588] Section 4.3.  [RFC3629]
> UTF-8 encoded 10646 characters are RECOMMENDED, but a robust
> implementation SHOULD support the field as undistinguished octets.

If it follows the IPFilterRule syntax, it never contains any characters
not part of US-ASCII, so mentioning UTF-8 is sort of redundant...

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 07:09:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Proposed Resolution to Issue 202: Diameter-RADIUS gateway behavior not spec'd
Date: Fri, 29 Sep 2006 00:09:19 -0700

The complete text of Section 4 now reads as follows:

"4.  Diameter Considerations

   [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the
   same functionality as the RADIUS NAS-Filter-Rule attribute.  In order
   to support interoperability, Diameter/RADIUS gateways will need to be
   configured to translate RADIUS attribute TBD to Diameter AVP 400 and
   vice-versa.  Where a Diameter NAS-Filter-Rule AVP contains a filter
   rule larger than 253 octets, Diameter/RADIUS gateways translate the
   AVP to multiple RADIUS NAS-Filter-Rule attributes, each with the same
   Tag field value not equal to '0' (0x30).  Similarly, when multiple
   RADIUS NAS-Filter-Rule attributes are received with the same Tag
   field value not equal to '0' (0x30), the String fields of the
   attributes are concatenated together and encoded as the value in a
   single Diameter NAS-Filter-Rule AVP.  RADIUS NAS-Filter-Rule
   attributes with a Tag field of '0' (0x30) are encoded as distinct
   Diameter NAS-Filter-Rule AVPs.

   Note that a translated Diameter message can be larger than the
   maximum RADIUS packet size (4096).  Where a Diameter/RADIUS gateway
   receives a Diameter message containing a NAS-Filter-Rule AVP that is
   too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
   will respond to the originating Diameter peer with the
   DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP
   containing the NAS-Filter-Rule AVP.  Since repairing the error will
   probably require re-working the filter rules, the originating peer
   should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error
   and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal
   error."

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>Subject: Proposed Resolution to Issue 202:  Diameter-RADIUS gateway 
>behavior not spec'd
>Date: Thu, 28 Sep 2006 23:48:12 -0700
>
>The text of Issue 202 is enclosed below.
>
>The proposed resolution is as follows:
>
>In Section 4, Change:
>
>"Note that since a Diameter AVP can be larger than the maximum RADIUS
>   packet size (4096), translation from Diameter to RADIUS may not be
>   possible in all cases."
>
>To:
>
>"Note that a translated Diameter message can be larger than
>the maximum RADIUS packet size (4096).  Where a Diameter/RADIUS
>gateway receives a Diameter message containing a NAS-Filter-Rule
>AVP that is too large to fit into a RADIUS packet, the
>Diameter/RADIUS gateway will respond to the originating
>Diameter peer with the DIAMETER_INVALID_AVP_LENGTH error (5014),
>and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP.
>Since repairing the error will probably require re-working
>the filter rules, the originating peer should treat the
>combination of a DIAMETER_INVALID_AVP_LENGTH error and
>a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a
>terminal error."
>
>
>------------------------
>Description of issue: Diameter-RADIUS gateway behavior not completely
>specified
>Submitter name: Glen Zorn
>Submitter email address: [email-masked]
>Date first submitted: 26 Aug 06
>Document: draft-ietf-radext-filter-01.txt
>Comment type: T
>Priority: 1
>Section: 4
>Rationale/Explanation of issue:
>
>The last sentence of section 4 says
>"Note that since a Diameter AVP can be larger than the maximum RADIUS
>packet size (4096), translation from Diameter to RADIUS may not be
>possible in all cases."  While this is true, the behavior of the
>Diameter-RADIUS gateway in this case is left unspecified.  Is the
>response forwarded back toward the requests' originator without the
>untranslatable AVPs?  In the case of an Access-Accept message, Section
>1.2 says "If a NAS conforming to this specification receives an
>Access-Accept packet containing a NAS-Filter-Rule attribute which it
>cannot apply, it MUST act as though it had received an Access-Reject.",
>it might be reasonable for the gateway to translate the Access-Accept
>into an Access-Reject, since an attribute that is missing because
>untranslatable can obviously not be applied.  In the case of a CoA
>message with an untranslatable attribute, should the message be
>translated into a Disconnect-Request or just discarded?  Or in both
>cases, should the gateway respond to the originating/responding Diameter
>peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
>let it figure out the next step?  If so, it still seems that the peers
>behavior must be specified.
>
>
>
>--
>to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 07:08:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADIUS attribute extension formats:  Do we understand the  proposals?
Date: Fri, 29 Sep 2006 00:08:02 -0700

In previous mailing list discussion, we have discussed two major proposals 
for RADIUS attribute extension.  This message attempts to summarize the two 
proposals.  Additions/corrections/comments welcome.

1. Glen + David's proposal:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Vendor-Id (cont)           | Extended type |    Length2    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Tag      |     Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

  Type

     26 for Vendor-Specific.

  Length

     >= 7

  Vendor-Id

     0 (for Extended Attributes)

  Extended Type

     0:       Reserved
     1-250:   Allocated by IANA
     250-255: Reserved

  Length2

     >=0

     Multiple subattributes MAY be encoded within a single Extended
     Attribute, although they do not have to be.

      Tag

      The Tag field is always present.  Values include:

         0:        Not Used (i.e. attribute is untagged)
         1-255:    Tag value used to aggregate attributes into groups

The value of the Tag field MAY be limited to printable ASCII values,
for ease of human entry and interpretation.

2. Alan DeKok's proposal:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |            Extended-Type      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Value...
    +-+-+-+-+-+-+-+-+

    Type

       TBD  (not 26)

    Length

       >= 4

    Extended-Type

       Two octets.

       0:  Concatenation
      1-255:  Reserved
      255-65530: Allocated by IANA
      65531-65535:  Reserved

    Value

       0-251 octets (Length - 4).

    Only a single RADIUS Extended-Type attribute may be included within
    a RADIUS attribute of Type TBD.   Where the value of the Extended-Type
    field is zero (0), this indicates that the content of the value field is 
to
    be concatenated with the contents of the value field in the previous
    attribute of Type TBD.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 06:57:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Strawman -02 Filter draft
Date: Thu, 28 Sep 2006 23:56:54 -0700

A strawman -02 version of the filter draft with the proposed resolutions to 
Issues 198 and 202 is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-02.txt

Comments welcome.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 06:48:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 202:  Diameter-RADIUS gateway behavior not spec'd
Date: Thu, 28 Sep 2006 23:48:12 -0700

The text of Issue 202 is enclosed below.

The proposed resolution is as follows:

In Section 4, Change:

"Note that since a Diameter AVP can be larger than the maximum RADIUS
   packet size (4096), translation from Diameter to RADIUS may not be
   possible in all cases."

To:

"Note that a translated Diameter message can be larger than
the maximum RADIUS packet size (4096).  Where a Diameter/RADIUS
gateway receives a Diameter message containing a NAS-Filter-Rule
AVP that is too large to fit into a RADIUS packet, the
Diameter/RADIUS gateway will respond to the originating
Diameter peer with the DIAMETER_INVALID_AVP_LENGTH error (5014),
and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP.
Since repairing the error will probably require re-working
the filter rules, the originating peer should treat the
combination of a DIAMETER_INVALID_AVP_LENGTH error and
a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a
terminal error."

------------------------
Description of issue: Diameter-RADIUS gateway behavior not completely
specified
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 26 Aug 06
Document: draft-ietf-radext-filter-01.txt
Comment type: T
Priority: 1
Section: 4
Rationale/Explanation of issue:

The last sentence of section 4 says
"Note that since a Diameter AVP can be larger than the maximum RADIUS
packet size (4096), translation from Diameter to RADIUS may not be
possible in all cases."  While this is true, the behavior of the
Diameter-RADIUS gateway in this case is left unspecified.  Is the
response forwarded back toward the requests' originator without the
untranslatable AVPs?  In the case of an Access-Accept message, Section
1.2 says "If a NAS conforming to this specification receives an
Access-Accept packet containing a NAS-Filter-Rule attribute which it
cannot apply, it MUST act as though it had received an Access-Reject.",
it might be reasonable for the gateway to translate the Access-Accept
into an Access-Reject, since an attribute that is missing because
untranslatable can obviously not be applied.  In the case of a CoA
message with an untranslatable attribute, should the message be
translated into a Disconnect-Request or just discarded?  Or in both
cases, should the gateway respond to the originating/responding Diameter
peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
let it figure out the next step?  If so, it still seems that the peers
behavior must be specified.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 29 Sep 2006 06:28:00 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Thu, 28 Sep 2006 23:27:23 -0700

The text of Issue 198 is enclosed below.  The proposed resolution is as 
follows:

Change Section 2 to the following:

"2.  NAS-Filter-Rule Attribute

   Description

      This attribute indicates filter rules to be applied for this user.
      Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
      Accept, CoA-Request, or Accounting-Request packets.

      The NAS-Filter-Rule attribute is not intended to be used
      concurrently with any other filter rule attribute, including
      Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
      SHOULD NOT appear in the same RADIUS packet.  If a Filter-Id
      attribute is present, then implementations of this specification
      MUST silently discard NAS-Filter-Rule attributes, if present.

      Where more than one NAS-Filter-Rule attribute with the same non-
      zero Tag field value is included in a RADIUS packet, the String
      field of the attributes are to be concatenated to form a single
      filter.  As noted in [RFC2865] Section 2.3, "the forwarding server
      MUST NOT change the order of any attributes of the same type", so
      that RADIUS proxies will not reorder NAS-Filter-Rule attributes.

      A summary of the NAS-Filter-Rule Attribute format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     Tag       |   String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      >=4

   Tag

      The Tag field is one octet, and MUST always be present.  It is
      used to identify the filter rule that is represented.  Where a
      single filter rule exceeds 253 octets in length, the rule MUST be
      encoded across multiple NAS-Filter-Rule attributes, each with the
      same Tag value; Tag values MUST be unique for each filter rule
      present in a RADIUS packet with the exception of a Tag value of
      '0' (0x30).  The value of '0' (0x30) in the Tag field indicates
      that the attribute contains a filter rule that does not exceed 253
      octets in length; as a result attributes with a Tag value of 0x30
      MUST NOT be concatenated, and one or more Filter-Rule attributes
      with a tag value of 0x30 may be included in a single RADIUS
      packet, each describing a single filter rule.

   String

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588] Section 4.3.
      [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a
      robust implementation SHOULD support the field as undistinguished
      octets."

-------------------------------------
Issue 198: Attribute Concatenation/Splitting
Submitter names: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: June 30, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00640.html
Document: Filter-00
Comment type: 'T'echnical
Priority: S
Section: 2 and 4
Rationale/Explanation of issue:
Section 2 currently says that "Where more than one NAS-Filter-Rule
attribute is included in a RADIUS packet, the attributes MUST be
consecutive and it is assumed that the attributes are to be
concatenated to form a single filter list."

I guess this means that a single long rule can be split into multiple
NAS-Filter-Rule attributes? And a single NAS-Filter-Rule attribute
could contain pieces of multiple rules? If so, I'd recommend
separating the individual rules somehow. In the current version of
NAS-Traffic-Rule each individual rule ends with LF, making it easy to
determine where one rule ends and another one begins. I'd suggest
adopting this same convention for RADIUS NAS-Filter-Rule.

This concatenation/splitting has also implications for Diameter
translation (Section 4): AVPs coming from Diameter side may have to be
split to several RADIUS attributes (and rule delimiters added), and
attributes coming from RADIUS side have to be concatenated/split to
Diameter AVPs (and rule delimiter removed).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Sep 2006 17:38:38 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
cc:
Subject: ISSUE: Table of attributes in RFC 4590
Message-Id: <[email-masked]>
Date: Tue, 26 Sep 2006 13:31:18 -0400 (EDT)

Description of issue: The table of attributes in Section 5 of RFC 4590
lists "0-1", or "0+" for all of the Digest attributes in the
Access-Request.  This would seem to indicate that we can have Digest
authentication where no Digest attributes exist in the Access-Request.

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Sept. 26, 2006
Reference: 
Document: RFC 4590
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:

The body text, and examples in Section 6 appear to indicate that at
least Digest-Method is required in every Access-Request.  Yet in
Section 5, the Table of Attributes indicates that no Digest attributes
are required in an Access-Request packet.

I first ran into this issue when I was looking at an implementation of
RFC 4590, and wanted to enforce the requirement that the
Message-Authenticator attribute must appear in every packet
implementing Digest authentication.  If the server sends an
Access-Accept or Access-Challenge packet with Digest attributes, it is
simple to determine that the Message-Authenticator must be included in
the packet.

However, for Access-Request, there appears to be no way to determine
if the request is, in fact a request for Digest authentication,
because there is no requirement that any Digest attributes exist in
the Access-Request.

Reading Section 1.3, the paragraph at the top of page 6 seems to
indicate that a Digest-Method is always sent in an Access-Request.
Other text in the document also indicates that the first
Access-Request always contains a Digest-Method attribute.

It may be that Digest-Method does NOT have to appear in Access-Request
if the Access-Request is in response to an Access-Challenge, but this
is not clear from the text.  My recommendation is to make
Digest-Method required in the Access-Request, which simplifies
implementation.  It also appears that this requirement is the intent
in RFC 4590, because all of the examples have Digest-Method in every
Access-Request.

I also have noted that none of the Access-Challenges in the examples
contain a State attribute, and the State attribute is not mentioned
anywhere in RFC 4590.  That indicates to me that the Access-Request in
response to an Access-Challenge MUST contain sufficient information to
finish the authentication process, and have the server return either
Access-Accept or Access-Reject.  The alternative is for the server to
repeatedly challenge the client, which does not appear to be the
intent.

That says to me that the Access-Challenge MUST contain a State
attribute, which is copied to the subsequent Access-Request.  The
server MUST respond with either an Access-Accept or Access-Reject to
an Access-Request that contains a State attribute.  The server MUST
NOT respond with Access-Challenge to an Access-Request that contains a
State attribute.

I believe that may be another issue.

Requested change:

Update the Table of Attributes as follows:

...
   | 1   | 0      | 0      | 0         | 108 | Digest-Method           |
...

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Sep 2006 12:52:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Serious error in RFC4590
Date: Sat, 23 Sep 2006 05:52:01 -0700

I agree that we need to get the IANA web pages corrected and also need to 
submit an errata to the RFC Editor.

However, I'm concerned that even with these measures, there is the potential 
for confusion to linger.  As I recall, the original RADIUS RFCs had to be 
re-issued to fix a port allocation problem.

I'm wondering what the WG thinks we should do in this situation.

>---------- Forwarded message ----------
>Date: Thu, 21 Sep 2006 09:21:55 +0200
>From: "Beck01, Wolfgang" <[email-masked]>
>To: [email-masked], [email-masked], [email-masked],
>     [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: AW: Serious error in RFC4590
>
>Alexander
>
> > In table 2 the Digest-Nextnonce and Digest-Response-Auth are
> > numbered 106 and 107. But furthur down they are numbered in
> > reverse order.
>This is ugly. The numbering is consistent in the main text
>and in the attributes table. The exception is section 7, IANA
>considerations. It's wrong in the IANA registry www.iana.org
>as well.
>
>Not an excuse, but an explanation: the IANA section is inserted
>at the end of the standardization process. It did not get the
>same attention and review time as the rest of the text.
>
> > If you already know about this problem I am sorry for
> > spamming you. But I feel it is important that this error
> > doesn't sneek it's way into implementations...
>
>Hopefully, the implementors will stick to the text and to the
>attribute table in section 5.
>
>I've cc'ed this mail to the chairs of the RADEXT WG. We should
>correct the IANA registry entries and issue an errata.
>
>106 is Digest-Response-Auth
>107 is Digest-Nextnonce
>
>Wolfgang
>
>--
>T-Systems
>Next Generation IP Services and Systems
>+49 6151 937 2863
>Am Kavalleriesand 3
>64295 Darmstadt
>Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Sep 2006 04:38:55 +0000
content-class: urn:content-classes:message
Subject: RFC 4672, 4673, 4675
Date: Thu, 21 Sep 2006 07:38:23 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Cc: "David Kessens" <[email-masked]>

Radext WG,

You must have seen by this time the announcements about the publication
of RFC 4672, RFC 4673, RFC 4675. Congratulations to the Working Group
for achieving these milestones and thanks to the editors for their hard
and perseverant work.=20

David and Dan

=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Sep 2006 23:44:14 +0000
Date: Wed, 20 Sep 2006 16:43:34 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4673 on RADIUS Dynamic Authorization Server MIB
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4673

        Title:      RADIUS Dynamic Authorization Server MIB 
        Author:     S. De Cnodder, N. Jonnala,
                    M. Chiba
        Status:     Informational
        Date:       September 2006
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      24
        Characters: 47635
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-dynauth-server-mib-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4673.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes the Remote Authentication Dial-In User
Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS)
functions that support the dynamic authorization extensions
as defined in RFC 3576.  This memo provides information for the Internet community.

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Sep 2006 23:44:06 +0000
Date: Wed, 20 Sep 2006 16:43:26 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4672 on RADIUS Dynamic Authorization Client MIB
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4672

        Title:      RADIUS Dynamic Authorization Client MIB 
        Author:     S. De Cnodder, N. Jonnala,
                    M. Chiba
        Status:     Informational
        Date:       September 2006
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      24
        Characters: 50817
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-dynauth-client-mib-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4672.txt

 This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes the Remote Authentication Dial-In User
Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC)
functions that support the dynamic authorization extensions as
defined in RFC 3576.  This memo provides information for the Internet community.

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Sep 2006 23:43:58 +0000
Date: Wed, 20 Sep 2006 16:43:41 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4675 on RADIUS Attributes for Virtual LAN and Priority Support
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4675

        Title:      RADIUS Attributes for Virtual LAN 
                    and Priority Support 
        Author:     P. Congdon, M. Sanchez,
                    B. Aboba
        Status:     Standards Track
        Date:       September 2006
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      15
        Characters: 29751
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-vlan-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4675.txt

This document proposes additional Remote Authentication Dial-In User
Service (RADIUS) attributes for dynamic Virtual LAN assignment and
prioritization, for use in provisioning of access to IEEE 802 local
area networks.  These attributes are usable within either RADIUS or
Diameter.  [STANDARDS TRACK]

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 15 Sep 2006 21:58:56 +0000
Date: Fri, 15 Sep 2006 17:58:23 -0400
From: Hannes Tschofenig <[email-masked]>
To: GEOPRIV <[email-masked]>,  [email-masked]
Subject: Draft Update: draft-ietf-geopriv-radius-lo-09.txt

Hi all,

I have submitted another draft update for the RADIUS-GEOPRIV draft 
draft-ietf-geopriv-radius-lo-09.txt.

Allison gave me feedback regarding the Operator Namespace and the IANA 
considerations regarding the Operator Namespace Identifier. Thanks to 
Allison for her help.

I removed two Operator Namespace Identifier, namely E212 and ICC
(see
http://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv-radius-lo-08.txt
), from the document since I wasn't able to find a contact person to 
list for the IANA consideration section regarding these identifiers.

I will contact our ITU-T liaisons to ensure that this is OK for them.

Please find the draft update here:
http://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv-radius-lo-09.txt

Ciao
Hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 13 Sep 2006 19:50:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-03.txt 
Date: Wed, 13 Sep 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Delegated-IPv6-Prefix Attribute
	Author(s)	: J. Salowey, R. Droms
	Filename	: draft-ietf-radext-delegated-prefix-03.txt
	Pages		: 8
	Date		: 2006-9-13
	
This document defines a RADIUS (Remote Authentication Dial In User
Service) attribute that carries an IPv6 prefix that is to be
delegated to the user.  This attribute is usable within either RADIUS
or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-delegated-prefix-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-delegated-prefix-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-delegated-prefix-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-delegated-prefix-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 05 Sep 2006 10:49:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Status of draft-lior-radius-prepaid-extensions?
Date: Tue, 5 Sep 2006 06:50:07 -0400
From: "Avi Lior" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, <[email-masked]>

Hi Glen,

Just to let you know about the status of this document.  We continue to
work it.

Just last week, WiMAX has adopted this work and will include it as part
of its WiMAX release 1.0 standard.

As for what will happen in the IETF with this work?  Not sure.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Monday, July 31, 2006 6:48 PM
> To: [email-masked]
> Subject: Status of draft-lior-radius-prepaid-extensions?
>=20
> Hi.  I'm just wondering if this is going to be adopted as a=20
> WG item, published as an individual submission or ?  Given=20
> that there are apparently at least a couple of independent,=20
> interoperable implementations it seems a bit silly to let it=20
> die on the vine...
>=20
> ~ gwz
>=20
> The Color Brown is a trademark.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>