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

From: "Michel Py" <[email-masked]>
Date: Thu, 2 Oct 2003 10:31:23 -0700

John,

> John C Klensin wrote:
> My ambitious in raising these questions are _very_ limited
> and, in particular, I don't see this as a back door to
> solving the non-DNS, topology-independent, persistent
> identifier problem. (It seems to me that needs to be solved
> through the front door, or not at all.).

I'm with you here. So, we know we need something more universal, but in
the meantime we band-aid FTP to keep going. Because of its special
status and the fact that it is widespread, FTP might justify doing the
work for only one protocol. It is clear that to be worthy of the effort,
this should be deployed way before a persistent identifier solution is
rolled out though.
As long as I'm not the one doing the work I don't have a problem with it
:-D

However, I do have a concern: when later a generic identifier mechanism
is deployed, we will have two standards. Have you had any thoughts on
the possible collisions there?

Michel.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Oct 2003 14:02:55 -0400

--On Thursday, 02 October, 2003 10:31 -0700 Michel Py 
<[email-masked]> wrote:

> I'm with you here. So, we know we need something more
> universal, but in the meantime we band-aid FTP to keep going.
> Because of its special status and the fact that it is
> widespread, FTP might justify doing the work for only one
> protocol. It is clear that to be worthy of the effort, this
> should be deployed way before a persistent identifier solution
> is rolled out though.
> As long as I'm not the one doing the work I don't have a
> problem with it :-D
>
> However, I do have a concern: when later a generic identifier
> mechanism is deployed, we will have two standards. Have you
> had any thoughts on the possible collisions there?

My goal is precisely to avoid ending up with either two 
standards or eight verbs.  Explanation of the latter:

      IPv4      IPv6 & self-referent  DNS    StableID
     address       address

RFC    959           2428           ???        ???
Verb  PORT,PASV    EPRT,EPSV     ?DPRT,DPSV? ?IPRT,IPSV?

That seems to me excessive, if we can avoid it.  So the 
suggestion is whether, given that 2428 is at Proposed, maybe it 
would be worth revising it, and the syntax for EPRT and EPSV, to 
_permit_ use of a DNS name now and to provide a clear extension 
path for a generic/stable identifier.

Too many DNS implementations are still having to support the "X" 
forms of the directory changing and modifying commands, and it 
has been a very long time.   All of them will need to support, 
esentially forever, PORT and PASV.  Ending up with eight verbs 
seems to me to be poor architecture, worse interface design, and 
a magnet for poor implementations.

--On Thursday, 02 October, 2003 13:39 -0400 Mark Allman 
<[email-masked]> wrote:

>...
> I think my hit to your narrow question is "no".  Sort of.
>
> It seems to me that the mechanisms defined in rfc2428 are
> working just fine.  Why go monkeying around with them?

I do not want to monkey around with those _mechanisms_.  I am 
objecting only to the syntax, which is extensible only by adding 
more verbs (see below).

>  It
> seems to me that the practical benefits of doing so would be
> quite small.  You may add a bit of flexibility in some cases,
> but you're also going to run up against a raft of new
> problems.  What are the practical benefits that we're going to
> get out of this exercise (i.e., how does this make FTP somehow
> better and not just "prettier" under the hood?).

In the, admittedly rare, situations in which the transfer is 
really third-party, and not even bound tightly to one of the 
other two, passing the domain name of the third host (one that 
is not at either end of the command connection) would seem more 
consistent with general architectural principles.  That seems to 
me to be especially true because, for those cases, the command 
connection host(s) are likely to get the pointer to that host in 
DNS name or URI form, not as an address.  In a world of NATs and 
split-horizon DNS setups (not that I like either), it seems far 
preferable to have the DNS name resolved from the host that is 
going to use the results to open a connection.   Again, this is 
a rare case but one that has occasionally been important with 
the IPv4 (and NCP) implementations of FTP.

> Now, if you had asked the question a little differently I
> might have answered differently.  If the question is:
>
>     Should we *add* a couple more verbs to FTP that are to be
> more     generic than the current verbs and allow for DNS
> names and other     "labels" we may come up with the in the
> future?  (With the     intent that the new verbs and the old
> verbs could co-exist.)
>
> Then I'd certainly be fine with that (assuming someone has the
> energy).  If these new commands end up taking over in the
> future then that's great and we can think about moving rfc2428
> to historic at that time.  But, I think the key here is that,
> IMO, we should *add*, not *replace*.

Aha.  Then we are having a difference of opinion about 
architecture and aesthetics, not function.  Putting in a new 
verb for the same function each time one wants to provide what 
is logically the same information in a different form impresses 
me as a bad idea.  You prefer it.  I don't know how to resolve 
that difference of aesthetic convictions other than with some 
"beauty is in the mind of the beholder" platitude... and that 
doesn't produce a resolution.

     john

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Oct 2003 14:54:37 -0400

> That seems to me excessive, if we can avoid it. 

If a case could actually be made for using DNS names in FTP
(and IMHO the case against is far heavier than the case in favor)
it would be a simple matter to define new "address types" for EPSV
and EPRT.  I don't see why new commands would be necessary.

> consistent with general architectural principles. 

Which principles are those?  That it's better to use an ambiguous
reference to a host than a unambiguous one?  That it's better to add
extra complexity and failure modes to a system than to use a simple and
reliable mechanism?  That it's better to encourage fragmenting the DNS
to reflect disjoint addressing realms than it is to encourage a sane
address space?

> That seems to 
> going to use the results to open a connection. 

It might seem that way, but experience indicates that DNS names are
_less_ reliable than IP addresses in referrals.  Because even with 
all of the harm done by RFC 1918 addersses, DNS is far more screwed up
in practice than IP.  Partly this is because DNS depends on even things
to be accessible, configured, and working properly in order to function
than IP does; and part of this is because there are more games played
with DNS than with IP.  And while use of RFC 1918 addresses at least
provides a clue that the address is not usable outside of the local
realm, there's no way to know whether a DNS name is globally usable or
not. 

And given the potential for a DNS name to produce different RRs at
different locations of the net (yes there are people doing this), it's
not clear at all that having the DNS name resolved from the host that is
going to use the address is the "right" meaning.   I would argue that
the lookup that is the closest to where the DNS name is _specified_ is
more likely to be the right one.   (Though I'd argue even more strongly
that producing different RRs at different locations is simply broken.)

At any rate, until someone defines a good way to make 3rd party FTP
transfers secure, any arguments about why DNS names are needed for 3rd
party transfers seem moot.

Keith

---

From: Mark Allman <[email-masked]>
Date: Thu, 02 Oct 2003 14:24:28 -0400

> architecture and aesthetics, not function.  Putting in a new verb
> for the same function each time one wants to provide what is
> logically the same information in a different form impresses me as
> a bad idea.  You prefer it.

No, I don't.  I share your desire to do something that is quite
generic and extendable and not end up with a ton of these commands.

My point was that EPRT/EPSV are working fine and rather than try to
kludge something on top of those why not just aim for a GPRT/GPSV
which would be very generic and general commands that could take any
sorts of identifiers of hosts that one might ever want to throw at
it.  That could be based on 2428, for sure.  That strikes me as a
clean approach.

(Oh ... and to resurrect another notion from the days of haggling
over the i-ds before 2428 ... I'd also think the transport protocol
stuff should be negotiated, as well.)

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/