[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Wednesday, March 15, 2006 6:18 PM
> To: radiusext@ops.ietf.org
> Subject: Attribute design thoughts (was RE: New Technical
> Issues RE: WG last call in progress on VLAN/Priority Draft)
>
> Emile van Bergen writes...
>
> > It was half serious. What I'm after is to find out at which
> point you
> > would start to agree that certain things are better only taken
> together.
>
> OK. I was reacting to your phrasing "all kinds of bad, bad
> magic". That doesn't move us forward, either.
>
> > We're having a theoretical debate, and you're not answering the
> > question. Let me try again. If RFC 2865 didn't have a time
> base type,
> > how would you propose a session time to be conveyed? As an
> attribute
> > consisting of subattributes allocated from a global IANA
> Type number
> > space, however wide?
>
> OK, theoretically speaking then.
>
> If there were no RADIUS time data type, then I would search
> to see if there were a standard one in common use, preferably
> one with a stable reference, e.g. an RFC. I would almost
> certainly choose Unix Epoch time (seconds since January 1,
> 1970) which conveniently fits in an Integer.
> If I were worried about the 2024 (or whenever) wrap-around,
> I'd find another standard representation, and use that (maybe
> an unsigned long long, i.e. 64-bit integer). If I were
> *forced* to use the representation you suggest, i.e. separate
> members of a structure for each of the "units" of time, and
> there were no existing standard I could reference, then I
> would look to the RADIUS Design Guidelines to see what is recommended.
>
> So, I haven't answered your question yet (but I will). My
> point up to this juncture is that the WG should reach a
> consensus on design guidelines, and then each individual
> attribute design decision should be made with the benefit of
> those recommendations, providing a certain level of
> consistency. This shouldn't be such an ad-hoc process, IMHO.
> I suppose this is a controversial opinion, something like
> advocating coding style standards. :-) While I have an
> opinion on this, I really don't care so much as to what the
> WG decides, as long as it comes to a consensus, and does so
> fairly quickly. I would prefer that the guidelines are
> substantive, and provide some real guidance, rather than
> simply codifying the existing ad-hoc practices.
>
> OK, so we're in an imperfect world, and the WG has not yet
> come to consensus on design guidelines, so I'm left to my own
> devices. How would I propose to encode the structure that
> you've presented as a hypothetical? Toss a coin? The
> problem is that in the absence of guidelines, it's a matter
> of personal style.
>
> How would I suggest that the design guidelines be worded to
> recommend encoding of structured data representations? My
> suggestion would be to use the Extended RADIUS Attribute
> (however it is ultimately defined) and use whatever grouping
> (data aggregation) method it supports to structure the member
> elements into a logical structure. This could be via
> sub-attributes, or via tagged attributes, or via grouped
> attributes (as in Diameter).
>
> I think it's important to reiterate some thoughts expressed
> elsewhere in this general discussion, however. One of those
> concepts is the issue of whether or not a RADIUS Server or
> RADIUS Client needs to take an action that depends on the
> value of one or more individual members of a data structure.
> So far, much of this discussion has been from the view point
> of RADIUS Servers, in terms of data dictionary
> implementations. We should also consider this from the NAS
> developer's viewpoint.
>
> If a RADIUS entity (Server or Client) needs to take some
> action dependent upon an element in a structure, it would be
> valuable and desirable to have the individual elements easily
> addressable. Having sub-attribute IDs for these is one way,
> and in an Extended RADIUS Attribute we can define this scheme
> without incurring any backwards compatibility penalties. We
> could also write custom string parser code for each
> individual attribute, which could work from fixed octet
> offsets, or could search for specified delimiter values in
> variable length fields. I personally find this kind of code
> more cumbersome, less flexible, less re-usable, and more
> error prone. It's certainly good job security for RADIUS
> developers. :-)
>
> If no RADIUS entity needs to take action on the values of the
> structure elements, e.g. it is passed to another entity (such
> as EAP), or it is simply intended to be dumped verbatim into
> a RADIUS Accounting Server log file, then it can perfectly
> well be densely packed into a string.
> My only concern with this approach is that the author of a
> new attribute
> *claims* that it can be treated as a string, because it's
> never parsed, when in fact implementations of that
> application eventually *do* need to have access to the
> individual data elements, and thus end up parsing densely
> packed strings.
>
> Another way to look at this issue, purely for the sake of
> analysis, is to see how the same data items would be encoded
> in ASN.1, using SMIv2, for a MIB. Pretend that we're using
> SNMP to provision the NAS instead of RADIUS. How would you
> write the MIB? You could easily see a relationship between
> leaf OIDs and RADIUS attributes (or sub-attributes). Now
> before anyone starts the flames, I realize that RADIUS is not
> like SNMP. For one thing RADIUS doesn't have a formal data
> model, like SNMP. I think the exercise is potentially
> instructive, none the less.
>
> If the eventual consensus of the WG is that individually
> addressable elements of a structure are not our cup of tea
> for attribute encoding guidelines, and that we really want to
> formalize the custom octet packing method for attribute
> encoding, then I could live with that, if it were algorithmic
> and predictable, from one attribute to another. One way to
> make such a scheme predictable would be to mimic the way a
> specified reference implementation of a C language complier,
> on a specified reference CPU architecture, would encode a C
> structure definition in physical memory, and simply clone
> that encoding method.
> One could handle the on-the-wire endian-ness with a simple
> mechanism such as the host-to-net and net-to-host macros
> (e.g. htonl, ntohl, etc).
>
> Any way we go, I'd *much* rather reach consensus on design
> guidelines and then be able to review proposed RADIUS
> extensions I-Ds against those concrete best current
> practices, rather than make ad-hoc evaluations of each new
> attribute against the personal opinions of the day.
>
The WG has already a number of RADIUS extensions documents in a more
advance phase than the Design Guidelines. Is the proposal to hold those
waiting for the reference to review against, or would these be treated
as part of the already approved and try to make the guidelines backwards
compatible with them? Moreover, does the WG considers thisa within the
scope of the Design Guidelines document, or do we need more
clarification or even an extension of the charter?
Dan
--
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/>