Hello Tom,
>> However, it does not discuss that an IP can (and should, IMHO) be given
>> through "host" if the point is to specify the target by its IP rather than
>> a lookup shortcut.
>
> Ah, that's the crux of the problem.
Yep!
> There are two ways that you could consider to be "best practice" for use
> of these parameters. The one that is currently documented is:
>
> 1. If you want to give a host name, put it in "host".
> 2. If you want to give a host IP address (to skip DNS), put it in
> "hostaddr".
> 3. ... unless your security arrangements require specifying a host name,
> in which case provide the host IP address in "hostaddr" and
> the host name in "host".
>
> What Fabien is basically proposing is replacing rule 2 with
>
> 2. If you want to give a host IP address (to skip DNS), put it in
> "host".
More or less. I'd rather rephrase it in two steps rather than 3, to
emphasize that it is simpler:
1. use "host" to provide the target whatever its form (name, ip, dir).
basically, always use host, which has always worked.
2. use "hostaddr" only to provide a ns shortcut on a provided name,
which can be real (the lookup would have provided the same answer)
or false (eg for testing purposes you really connect to another
host). Basically nobody should ever do that but in special use cases.
> While that would perhaps be an equally good best practice if we'd
> started there, it's not clear to me that it has any advantage that
> would justify changing the recommendation.
Simplicity and clarity: less thing to remember, just always use "host"
for the target.
> In particular, the existing rule is a lot clearer from a data-type
> standpoint: host is for names, hostaddr is for IP addresses.
Hmmm, I do not buy the typing argument: "host" is actually for everything,
including directories. I do not think that adding "hostdir" would be
desirable.
> In any case, the existing doco never comes out and states either
> rule set in so many words. Maybe it should.
--
Fabien.
