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

John,

The extensions in 2428 are in wide use, and they work just fine.  I
don't see any reason to change them.  

Nor do I believe there is consensus that applications should always be
passing names in preference to IP addresses.  And until there is a
system for assigning stable names to hosts that are independent of
any administrative domain (since hosts often don't live in a single
administrative domain), and quickly and reliably mapping from those
names to IP addresses, the idea that applications should pass names in
preference to IP address is something that I would classify "fantasy" 
at best.  In particular, DNS is not sufficient to replace IP addresses
in this role.

see also 
http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id.html

Keith

> I just had occasion to look again at RFC 2428, "FTP Extensions 
> for IPv6 and NATs",  M. Allman, S. Ostermann, C. Metz. September 
> 1998, and to think about in the context of the recent 
> flame-war^H^H^H^H^H^H^H^H^H discussions about use of IP 
> addresses in applications.   2428 provides additional syntax and 
> mechanisms for FTP to deal with IPv6, with some useful 
> properties for NATs (useful if you believe in NATs).  It appears 
> to provide only for addresses and does not appear to be 
> extensible except to the addressing formats of new versions of 
> IP.
>
> It seems appropriate to ask whether 2428 should be opened and 
> given at least the capability of passing DNS names and maybe 
> some syntax that would permit clean extension to future 
> identifiers.  In the unlikely event that there is insufficient 
> interest or energy to do that work, should it be moved to 
> historic or otherwise given a "not recommended" status as 
> potentially harmful and inconsistent with the principle that 
> applications (especially for IPv6) should be passing names and 
> not IP addresses?
>
> Please consider this a fairly narrow question.   I don't want to 
> start either the "applications level identifiers" debate or the 
> NAT wars again and they aren't necessary to answering the 
> question.  On those topics, please, everyone, your points --pro, 
> con, or otherwise-- have been made and anyone who is going to be 
> convinced has been convinced.  More traffic on those subjects in 
> the guise of responding to this question will just convince more 
> people that it is impossible to carry out a technical discussion 
> on the IETF list.