RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]

["D. B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

>> My immediate suggestion: Don't put a RADIUS / Diameter compatibility
>> considerations section into the document as it is almost always wrong. 
>
>  I'll have to ask the chairs about this...

<Chair Hat = on>

I don't think it's OK to simply "punt" on Diameter interoperability
considerations in RADIUS extensions work.  It's in the RADEXT charter, for
good reason.

I agree that the boilerplate text we've been using recently is flawed.  It's
not enough to effectively say "just follow NASreq".  There are a number of
issues to address, with complex AVP encoding and Application IDs being top
of mind.  It seems to me that the authors so RFC 4005 thought about
importing all of the RADIUS attributes that existed at the time that
document was published under the NASreq Application ID, but not about future
RADIUS extensions.  The whole mandatory attributes vs. new application IDs
thing is a major headache that, IMHO, DIME needs to solve.

We need tome assistance from folks in DIME, and we may need them to create
an RFC 4005bis, or some such.

I don't think we can simply omit discussing Diameter compatibly and
interoperability.

If there is a good reason why Diameter interoperability (ease of gateway) is
not required for a given application area, then we can simply say that in
the document -- don't bother trying to import these attributes into
Diameter.

<Chair Hat = off>



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