RE: RADEXT charter, Take 8

["Nelson, David" <dnelson@enterasys.com>]

Joel Halpern writes...

> I find this confusing.  Let us use prepaid as an example.  We are
> discussing an RFC on RADIUS prepaid.  This RFC defines a set of
behaviors
> to be used by RADIUS client and server.  It defines a set of AVPs to
be
> passed between these two entities.  None of the specification has any
> effect on the RADIUS processing logic, RADIUS routing, or RADIUS proxy
> behavior.  No devices which are not actively supporting pre-paid are
> affected by this work.  No new messages are introduced.

Are suggesting that there are two classes of RADIUS entities, (a) those
that need to understand pre-paid data elements, and (b) those that do
not?  That would seem to be the logical implication of your assertion
that complex, hybrid data elements (i.e. not "one data element, one
AVP") would not impact the "RADIUS processing logic".  

I think I have heard others make this type of argument.  It goes along
the lines of "What harm is there in re-defining the RADIUS data formats,
since it's only RADIUS products manufactured to serve the pre-paid
market segment that would need to be modified to 'understand' the
content of these new formats?".

For my part, I reject the notion of two classes of RADIUS products.  You
either have multi-vendor interoperability in a protocol or you don't.
It's akin to the notion of being "partially pregnant" -- an oxymoron.

> Now, is that a RADIUS or Diameter RFC?  It seems that if we want to
> include opaque blobs of information we should declare that the 
> description is not a RADIUS or Diameter RFC.  It would seem very odd
> to declare that this work needed to be done in a non-RADIUS 
> non-Diameter working group since the only interesting supporting
> protocol is RADIUS.

Exactly to my point!  Either this is RADIUS or it isn't.  You can't have
it both ways.  By that, I mean that data elements can't be "out of
scope" for multi-vendor RADIUS protocol interoperability concerns and at
the same time "in scope" for the RADEXT WG.

> The distinction you are drawing (in a RADIUS or Diametter RFC) does
not
> seem to relate to any aspect of protocol compatibility or on the wire
> behavior.  Normally, the IETF tries to be more interested in whether
the
> protocols we define make sense on the wire than on how we label the
> documents we put them in.

You misunderstand my point.   The issue is not document labels, but
whether a data item communicated within RADIUS datagrams is "RADIUS" or
something else.  If it is RADIUS, it needs to be restricted to fall
within the approved and widely deployed RADIUS protocol architecture.
If it isn't RADIUS, it should be dealt with in another WG.

BTW, I wish to remind folks that the IETF has already dealt with the
question of defining a RADIUS-Plus protocol, in the early days of the
AAA WG.  That approach was rejected in favor of standardizing Diameter.
We ought not, IMHO, attempt to revive the notion of a RADIUS-Plus
protocol.  We are doing RADIUS Extensions, which implies a high level of
backwards compatibility.

-- Dave


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