Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

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

"Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
> As far as I can tell, the purpose of including any typing at all in
> RADIUS is to enable support for new attributes by addition of
> dictionary entries, without changing code.  This is not just an
> academic point about "data models" -- this has real impact on
> customers.

  Yes.  The other side of this requirement is that new functionality
that requires *interpretation* of the attribute content may require
new types in the dictionary.  This hasn't historically been a problem
for implementors.

  That is, the dictionaries exist to solve the 99% common problem,
where vendors need to send a string/integer/ipaddr in RADIUS to their
box.  Server vendors then can update dictionaries without changing
server code.

  In this model, the VLAN format fits just fine.  It's an ASCII string
with magic format.  That's no different than other magically formatted
text strings like in RFC 2865:

5.22.  Framed-Route
...
      That is followed by a space, a gateway address in dotted quad
      form, a space, and one or more metrics separated by spaces.  For
      example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400".
...

  There may be others, but that's the first one that springs to mind.
Multi-field text strings are well within common RADIUS practices.

> The issue is really about attributes sent from the client to the server.  As 
> Emile noted, if the attribute sub-elements don't need to be addressed 
> individually, such as if they are always handled as an opaque blob, then the 
> attribute can be treated as type "STRING" by the server, and existing 
> implementations will work just fine, so there is no issue.

  I concur.

> As far as I can tell, while compound attributes have a rich history within 
> RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have 
> any compound attributes been introduced which require individual addressing 
> of sub-elements.  So as far as I can see, it is not use of "compound 
> attributes" but rather "individually addressable sub-elements" that 
> represents the critical distinction here.

  That's a good summary.

  For this draft, the semantics of the attribute would not change if
the document was updated to make it an attribute of type "text"
containing no embedded fields.  The description text could then add
that the format had special requirements: the VLAN name should be
prefixed with an ASCII "1" or "2".

  If we go down that route, I would *then* say that there should be a
space between the two fields, just to address human issues.
Administrators can readily interpret multi-field text strings, if the
fields are separated by spaces.  As the document exists today, there
are human interpretation issues, as was earlier pointed out.

  Still, I'm OK with it as it is.  I had no objections during the whol
review process, so it would be a little inopportune to comment now.

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