RE: DISCUSS and COMMENT: draft-ietf-radext-design

["Dave Nelson" <d.b.nelson@comcast.net>]

> >   Vendors cannot create VSAs of both 8 and 16 bits with the same
> > Vendor-Id.  Some have tried, and have quickly fixed their product when
> > *everyone* complained.
> >
> >   If vendors want to "switch" to using 16-bit types, they need to use a
> > new vendor-id.
> >
> 
> Ok. I didn't think that was the case but clearly you have the
> operational experience on this.
> 
> I think it would be essential to spell this out in the draft -- its
> important information!

Quite frankly, this line of reasoning disturbs me.  It's well known that
there have been all sorts of non-standard behaviors (and a few ugly hacks)
implemented in RADIUS clients and servers over the years.  Dave Mitton
documented some of these in RFC 2882.  This document is a BCP.  That means
it should document the *best* current practices and not the more dubious
ones.  Not all hacks are created equal.

This document should aim to bring order out of chaos.

I think it would be fine if the Extended Attributes have 16-bit IDs and the
traditional RFC 2865 format VSAs kept their 8-bit IDs.  Anything else, e.g.
non-standard VSA formats, is simply "off the reservation" and outside the
scope of this document.



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