[MIPSHOP-MIH-DT] FW: DNS Early Warning: Score 40: Mobility Services Transport ProtocolDesign

 Do you see the mail from Peter?

 Best Regards, Sam Xia
-----Original Message-----
From: Peter Koch [mailto:peter@denic.de] On Behalf Of Peter Koch
Sent: Friday, October 05, 2007 9:28 PM
To: Jari Arkko
Cc: dns-dir@ops.ietf.org; dhc-chairs@tools.ietf.org; Mipshop Chairs
Subject: Re: DNS Early Warning: Score 40: Mobility Services Transport
ProtocolDesign

On Fri, Oct 05, 2007 at 03:55:40PM +0300, Jari Arkko wrote:
> Thanks for the review! Has anyone looked at the other document? I 
> think we need to.

I did, a while ago.  What bothers me that this is another attempt to use the
DNS as a discovery mechanism, which is fatally wrong in my opinion.  The
draft <draft-bajko-mos-dns-discovery-00.txt> has some particular issues with
using NAPTR based on RFC 2915 instead of DDDS and with specifying fallback
mechanisms which have proven a bad idea in, e.g., the MX/A case.

However, the fundamental problem I have with this approach is that it
assumes that the searching entity is "in" a domain and knows about that.
This more or less immediately leads to some DNS search (-> tree climbing;
the draft mentioned above isn't specific about this, but similar approaches
are) and it violates a paradigm that I consider important: it uses the DNS
to publish information _for_ a domain (whatever that is) instead of
information _about_ a domain.

Assuming that a system knows which domain it is "in" means you can't have
stable names, i.e., I want my laptop to be "unknown.denic.de" regardless of
where it is. Then, using the config details published under "denic.de"
probably won't help me when accessing the net via some hotspot that uses DNS
based service discovery.

There's a similar problem with a document in geopriv and a more recent one
discussed on the int-area list which try to base servcie location on the
availability and maintenance of the DNS reverse mapping.  That's slightly
better, because it bases sloc on location (through addresses, represented as
reverse mapping entries), but still uses the DNS the wrong direction IMHO.

-Peter

_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt