Re: Persistent applications-level identifiers, the DNS, and RFC 2428

> Keith, you are starting down the path I was hoping to avoid, so 
> maybe my specific concern and suggestion wasn't clear.  If is is 
> working well as is, then I withdraw even the hint of deprecating 
> the thing.    My main objection to 2428 is not that it _permits_ 
> addresses, but that it provides no option other than addresses 
> and nothing on which to hang a DNS name or other identifier if 
> one has one.  That, it seems to me, is poor protocol design 
> going forward, since it implies that the next new identifier 
> requires yet another set of command keywords.
I disagree.  A host, at least one on the public Internet
(where IP addresses are globally unique as IP was designed to work) has
reliable knowledge of its current IP addresses.  It does not have
reliable knowledge of which DNS names are currently bound to its IP
addresses, nor of the intended purposes of those DNS names  (are the
names intended to be associated with a particular host or with a
particular service that is supplied by many hosts?).  

So expecting, or even allowing, an FTP client or server to say 
"contact me at this DNS name" seems to me to be providing additional 
ways for the FTP session to fail, while adding little (if any) value.
e.g. 

- the party providing the DNS name may be doing so erroneously,

- the DNS servers providing name-to-address translation might not
  be in service and reachable,

- DNS lookup might not be available to one party or another
  (e.g. one party is on a ad hoc network and wants to use LLMNR,
  while the other party is on a connected network and expects
  DNS to work)

- if there is an intermediary involved, use of the DNS name may 
  confuse the intermediary or one or the endpoints.  for instance, 
  it is often possible to use FTP between hosts in different
  addressing realms via use of an intermediary, while DNS names
  would fail in those situations.

I'll also note that RFC 2428 already provides a way (EPSV) to  establish
FTP transfers in the usual case where the file is being transferred
between client and server and no third party is involved, which doesn't
need *any* kind of name - neither IP address nor DNS name - as the
endpoint addresses are implicit.  This should be used in the vast
majority of cases.

More fundamentally, of course, I have issues with the citing of
"applications should use names rather than addresses" as a principle to
which there is widespread agreement, and which should drive protocol 
designs, or even as something which has been demonstrated to be
workable.   We don't need to revisit that discussion again right now, or
in this context, but neither should it be taken as a given.  (Nor does
this really have anything to do with NAT - the two are only tangentially
related.)

If we're only looking at the narrow question of FTP, I submit that EPSV
is good enough for the vast majority  of cases, EPRT with either v4 or
v6 addresses is good enough for 3-party transfers (assuming that you can
manage the security issues), and any marginal value that would be
provided by adding DNS capability is fairly dubious at best and
potentially harmful.