Re: IPv6

[Alan DeKok <aland@deployingradius.com>]

Wojciech Dec (wdec) wrote:
> So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT
> changing existing attributes and the draft does not propose anything for
> which there isn't a precedent (see rfc2868, rfc3162). 

  I think we're really talking about different things.  I keep trying to
explain that the draft is doing something *new*.  You keep claiming it
isn't.

> Overall, thanks for educating me, but perhaps you should take a step
> back: In draft-lourdelet we're defining the on-the-wire format of these
> new attributes. The data-type used for internal bindings of these
> attributes is an implementation detail, which you (and perhaps others)
> appear to make a business of the Radext WG (it seems that while new to
> Radext, I haven't been missing out on much fun after all). 

  The "implementation detail" you're arguing about is discussed in the
design guidelines document.  It's something that comes up in this WG,
and in others.  Implementation details are relevant, and cannot be
dismissed with a wave of the hand.

> Now, even if that were justfiied, with a definition of "string" like the
> one above you have no right to claim that a "string" data-type cannot be
> used for sending an arbitrary sequence of 1-255 octets of/in whatever
> encoding.

  I think you have a problem reading my messages.  I didn't claim the
"string" type wasn't suitable for sending arbitrary strings.  I said
that you couldn't have it both ways:  (1) claim that it's an attribute
with a strongly typed definition (tag + integer), and (2) claim that
it's also an arbitrary sequence of octets.

  It's about consistency.  I like it.  You're not following it.

>>   Otherwise... please suggest how implementations can do the 
>> impossible, and encode these new attributes using a novel 
>> format, without adding a new encoding method.
> 
> Uhm, for the IPv6-Prefix attribute one could have one of the following
> abstract definitions (all of them with no new exotic data-types other
> than those likely already used)
> 
> struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t
> prefix; };

  Please point out where the "struct" type is defined in the RADIUS
specifications.

  You can't.  It isn't defined anywhere.  You invented it, and claimed
that it can be used in RADIUS, and that it's just an "implementation
detail".  It's not.

  If this was Diameter, this would be possible.  Diameter defines a
grouped attribute, which can be used to group arbitrary other attributes
(i.e. data types) into a "struct" like object.

> May I suggest that once more you're confusing on-the-wire format with
> internal data-type representation.

  Uh... the internal data types represent at *least* the on-the-wire
format.  If they didn't, the data types couldn't be encoded onto the wire.

> It would seem that according to you
> each attribute in Radius with some internal structure not seen
> previoulsy is effectively a new data-type

  Don't blame me.  That would appear to be the consensus of this WG, as
written in the design guidelines document.

> and that this needs to be
> enforced by the Radius specs. I'll call these non-atomic-data-types to
> differentiate from what I consider common atomic data-types that rely on
> common types/units of data (unit 32, etc). It's from the perspective of
> non-atomic-data-types that draft-lourdelet *may* indeed be seen to call
> for something new. It "may* but *it doesn't have* because that's again
> all up to *implementation detail*.

  Ignoring implementation details won't make them go away.  This draft
*gratuitously* introduces new data types where existing ones could be
re-used.

  That's not an implementation detail: it's bad design.

> All this shows how pointless is defining the protocol *and* such
> non-atomic-data-type implementation specifics at the same time. The
> protocol spec should not go into implementation specifics and your
> argument around why it should be otherwise is rather unsubstatiated.

  Strange.  I could have sworn I was writing messages explaining my
position.  Did you read them?

  RADIUS servers have historically been been driven by data
dictionaries.  See Section 2 of the design guidelines document.  This
isn't an "implementation detail".  It is billions of dollars of
equipment in hundreds of thousands of sites.

  Some implementations have simple dictionary support, others support
complex dictionaries.  But this "implementation detail" needs to be
taken into account when writing new specifications.

> Draft-ietf-radext-design-08.txt doesn't do better, if actually being
> misguided in some of these aspects.

  I suggest that you post a separate review of the document. It's clear
that you have valuable input which could make the document better.

> It would help all if you could be a bit more constructive... 

  By all means.  Simple specifications that leverage existing
implementations are good.  Specifications that follow historical
practices are usually a good idea, too.

  I am encouraging good practice.  Part of this involves pointing out
bad practices, and explaining why they're bad.  If you think this is not
constructive, I suggest you avoid peer review entirely.

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