Re: SRV vs. A/AAAA RR lookups

[Stefan Winter <stefan.winter@restena.lu>]

Hello,

> Given this, it would seem that the argument rests on whether these
> additional parameters are useful or whether they typically just 
> represent additional overhead.  The AAA WG leaned toward the 
> latter, but the RADEXT WG can make its own decision. 
>   

I have to say I'm very much in favour of having the option to discover
the port. If a given server hosts two instances of a RadSec peer, it
will have to use different ports. There are cases where people want to
or have to deploy two separate instances. E.g. if clients do not send
the CA indication, and the server is in possession of multiple
certificates. Typical workarounds for the lack of server certificate
selection possibilities so far in our static setup were that two
instances were created, and clients configured to the instance which had
the "right" ceritificate to present.
Having the flexibility of a SRV lookup does not look like unnecessary
luxury to me.

> It is harder
> to make a case for the weight field, since any desired load 
> balancing can be achieved by shuffling of A/AAAA RRs.  

I'm not even sure about that. In my experience, shuffling A's (I suspect
you mean adding multiple A's for one host name in a zone file) does not
lead to any deterministic result, since both authoritative name servers
and resolvers can autonomously re-order what they got from upstream. One
of the scenarios that can't be modelled in this case is that a deployer
has a server he considers "primary" (i.e. which should usually handle
*all* requests for a realm) and a "backup" (which shouldn't get any
requests unless the primary is down). I'm having trouble imagining how
such an intended behaviour can be put into A/AAAA semantics at all.

All in all, I would prefer SRVs very much.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


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