RE: RADIUS attribute extension formats: Do we understand the proposals?

["Avi Lior" <avi@bridgewatersystems.com>]

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: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 3:08 AM
> To: radiusext@ops.ietf.org
> Subject: RADIUS attribute extension formats: Do we understand 
> the proposals?
> 
> 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 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/>