Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Tue, 06 Sep 2005 12:49:09 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DEFF320091 for ; Tue, 6 Sep 2005 12:49:09 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22337-03 for ; Tue, 6 Sep 2005 12:49:03 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6494832008A for ; Tue, 6 Sep 2005 12:48:58 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECau5-0006Ci-4G; Tue, 06 Sep 2005 06:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECau1-0006CV-KQ for ietf@megatron.ietf.org; Tue, 06 Sep 2005 06:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19164 for ; Tue, 6 Sep 2005 06:42:07 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECawy-0000nS-VP for ietf@ietf.org; Tue, 06 Sep 2005 06:45:13 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1ECato-0003zD-02; Tue, 06 Sep 2005 03:41:56 -0700 Message-Id: <6.2.3.4.2.20050906111920.04aebeb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 06 Sep 2005 12:41:46 +0200 To: Iljitsch van Beijnum From: "JFC (Jefsey) Morfin" In-Reply-To: <55C9F301-48A4-437E-9DDD-4F9EDB6B3DE0@muada.com> References: <6.2.3.4.2.20050905110227.0446ac40@mail.jefsey.com> <431C29CB.50707@peter-dambier.de> <200509051202.j85C2E9j010464@burp.tkv.asdf.org> <1125922890.792.31.camel@firenze.zurich.ibm.com> <97A7E86E-BC37-42EC-9CB8-AEA1AE4C8E05@muada.com> <6.2.3.4.2.20050906003458.05ddceb0@mail.jefsey.com> <55C9F301-48A4-437E-9DDD-4F9EDB6B3DE0@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF General Discussion Mailing List Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no At 10:12 06/09/2005, Iljitsch van Beijnum wrote: >On 6-sep-2005, at 1:48, JFC (Jefsey) Morfin wrote: > >> > So for those people that aren't capable of running their own DNS, > >>I agree with everything you say. But with this one. I think the >>problem is there is no free Linux/Windows nameserver with a smart >>enough control panel for everyone being able to run their own DNS. >>May be a project to dig into rather than to endanger the DNS? > >It would be an interesting experiment to make an easy-to-use DNS >implementation for local use that runs on a residential gateway. But >to be part of the global DNS requires delegation pointers from >elsewhere, and most residential/SOHO users don't have addresses that >are stable enough to make this usable. This may change with IPv6, >though. I am afraid not. The real digital divide is between those who can be called and those who cannot by lack of money for an IP address (the cost of an IPv6 address is also the software change, education, missing user tools). This results from an old and costly model (RIRs) rather than using a network model (like telephone). This was needed in a deployment period, this is a blocking factor for a mature global network continuity. It is a real shame that the entire world has E.164 numbers, with billions of people paying them every month, using every days, possibly keeping them all their life long, using them for the telephone, as customer ID, when they want to be differentiate from homonyms in databases, etc. and they cannot use on the ... modern ... Internet. By the ITU or by the RIRs, what is the problem to have an IPv6 plan made of a leading byte+telephone number? What is the problem of entering a telephone number in a browser and to access the corresponding byte+telnr IPv6 address? In the meanwhile is there an impossibility to think of small softwares acting as a local name server and as an external resolver. Is there a major problem in having the IP addresses managed dynamically (mobile systems would need them anyway)? Is there a big problem to get a hook before or after Hosts.txt so anyone can organise the responses he wants, for his applications? I think the real problem is to gather a DNS reference book. So the specs, the functions, the tricks of the protocol, the samples of existing code are documented authoritatively, a test bed is organised and new people with fresh ideas can come, learn and realistically develop new projects without being shout at "RFC XXXX!" or start an IETF war. mDNS and LLMNR are just that: working ideas. In 22 years should we not have had a lot more? They represent a danger for the DNS? May be, only if the DNS is not fool proof or at least resilient enough or embedded in a more global system the user has an immediate interest to protect because it would affect much more, like in the DRS (distributed registry system I alluded to and which seems an interesting area of research). IMHO it is in that directions the IETF should work. Anyway do not worry too much about a DNS network overload, without a DRS the langtags support may do better and faster. jfc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf