RE: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Just out of curiosity, why are we doing this?  In the revision of RFC
> 3588,
> > the dime WG has pretty much removed this capability because it was
> used by,
> > well, no one.  If it actually used by EDU Roam, that's fine, but does
> it
> > need to be standardized?
> 
>   I believe so.  There is interest in using this process inside of a
> trusted network.

Inside of a trusted network?  Isn't this, then, a configuration issue,
rather than a standards issue?

> 
>   e.g. An enterprise would configure NASes with CA && client
> certificates.  The NAS would use DNS to discover the server, and then
> use SSL to communicate with it.
> 
>   This has obvious benefits for operational networks.

Maybe you could explain those benefits (and why they were not exploited by
the folks deploying Diameter).  The only real benefit I can see is in the
case where a new server is added to the network or the IP address of an old
one is changed (surely a rather rare occurrence).  Are there others?

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