Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01

[Sebastien Decugis <[e-mail]>]

 Hi again Glen,

> Precisely the problem: the necessity to provide for RADIUS compatibility
> unnecessarily constrains the content of the Diameter AVPs.  In fact, NASREQ
> is not so much a Diameter application as RADIUS in a Diameter wrapper.
This holds only when the Origin-AAA-Protocol AVP is present; otherwise
there is no such limitation in the RFC, as far as I know.

> Removing the need to artificially limit the length of the NASREQ AVP
> payloads to 253 (or even 4073) octets would make NASREQ into a _real_
> Diameter application.
(see previous comment)

>>> In any case, if they decided to migrate to Diameter they could use the
>>> pointless tunneling protocol, retiring their RADIUS server when the
>>> transition was complete.
>> You are implying that each domain can retire its RADIUS server only when
>> *all* the domains have moved all their clients to Diameter... This
>> reasoning may be possible in a single-domain context, but it does not
>> hold in a multi-domain roaming consortium case.
> Care to give some sort of rationale for this statement?
Well, assume domain A is still using RADIUS and domain B has moved all
its equipment to Diameter.
Now a user from domain B is accessing the network through a NAS in domain A.

NAS-A -> RADIA agent (in RADIUS)
RDR -> domain B in Diameter.
Now, one needs to de-tunnel the RADIUS message from the RDR and then
have a RADIUS stack to interpret this message, right?
Hence my comment that we cannot get rid of RADIUS in domain B until all
domains in the consortium have moved to Diameter...
In addition, with RADIA you loose the benefit of Diameter applications
allowing to route different applications to different servers.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)