Re: Extended attrs doc

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> Slightly off-topic -- wanted to point out proxies seem to be allowed to
> add add attributes anywhere they want in a packet while still respecting
> ordering constraint of RFC 2865 2.3.

  Yes.

> I believe practically if this type of encoding were wrong the situation
> would be detected quickly in any reasonable interop test.  It is the not
> so obvious interactions between systems and extension attributes I'm
> most concerned about.

  People do interop tests?  Maybe I post a list of vendors who've
blatantly violated the RFCs and interoperability.

> Don't think this applies to extensions VSAs.  In 4.6 Vendor Type is
> explicitly defined as a single byte.
> 
> "The Vendor-Type field is one octet.  Values are assigned at the sole
> discretion of the Vendor."
> 
> This type has a more flag so thinking we would expect the same encoding
> rules for all extensions VSAs where it came to fragmentation.

  Yes.  The top-level VSA can be fragmented.  Anything *inside* of that,
such as sub-TLVs, cannot be fragmented.

> If I had to choose between a more flag and the counter I would pick the
> counter.
> 
> Prefer combination of more and counter since it gives you the end marker
> to detect truncation.

  Or, start the counter at the last fragment.  Counters go N, N-1, N-2,
..., 1, 0.  If the list is truncated, it doesn't end at zero.

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