RE: RADEXT charter, Take 8

["Joel M. Halpern" <joel@stevecrocker.com>]

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.

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.  And even more so since we would 
like to be consistent with the existing work in the DIAMETER space (subject 
to not introducing new messages and other RADIUS restrictions.)

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.

Yours,
Joel M. Halpern

PS: It is not impossible to define reasonable restrictions on the use of 
AVPs to avoid opening a pandora's box of complexity.  But the distinction 
proposed here does not seem to help.  And presumably it is not reasonable 
to declare that we need to wait a year while we reach agreement on what AVP 
forms are acceptable.  We need something simple.

At 08:10 AM 3/25/2004 -0500, Nelson, David wrote:
> I'm not sure I agree with your assessment, without reviewing the
> archive.  However, I think the key issues with consensus acceptance of
> strings is whether they fall into one of two cases: (a) limited parsing
> is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
> *ever* parse the strings, it passes them as opaque "binary blobs" to
> some other protocol, as in the case of EAP-Message.  In order to qualify
> as "some other protocol", the elements, syntax and semantics of that
> protocol can't be defined in a RADIUS or Diameter RFC.


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