scott.rose@nist.gov
+1 = 301-975-8439
Google Voice: +1 = 571-249-3671
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Jun 14, 2012, at 1:25 PM, internet-drafts@ietf.org = wrote:

A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of = the DNS Extensions Working Group of the IETF.

Title =           : Signaling = Cryptographic Algorithm Understanding in DNSSEC
Author(s) =       : Steve Crocker
=             &n= bsp;           &nbs= p;Scott Rose
= Filename        : = draft-ietf-dnsext-dnssec-algo-signal-07.txt
Pages =           : 8
Date =            : = 2012-06-14

Abstract:
  The DNS Security Extensions = (DNSSEC) were developed to provide origin
  authentication = and integrity protection for DNS data by using digital
=   signatures. These digital signatures can be generated = using
  different algorithms. This draft sets out to = specify a way for
  validating end-system resolvers to = signal to a server which digital
  signature and hash = algorithms they support.

The IETF datatracker status page = for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal=

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-07<= br>
A diff from previous version is available = at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-= signal-07

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
dnsext mailing = list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

= --Apple-Mail=_271E5361-3271-4B6F-B5B4-C6B92FA5FA6B-- From fanf2@hermes.cam.ac.uk Thu Jun 14 11:09:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D42921F8734 for ; Thu, 14 Jun 2012 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrsN5xMasMvL for ; Thu, 14 Jun 2012 11:09:14 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id DE04421F8732 for ; Thu, 14 Jun 2012 11:09:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45621) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SfETn-0002HI-qk (Exim 4.72) (return-path ); Thu, 14 Jun 2012 19:09:11 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SfETn-0002Y5-9Z (Exim 4.67) (return-path ); Thu, 14 Jun 2012 19:09:11 +0100 Date: Thu, 14 Jun 2012 19:09:11 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Roy Arends , RJ Atkinson , SN Bhatti , Scott Rose In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] DNS RRTYPEs for ILNP review - Comments period end July 5th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:09:15 -0000 > http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt This looks OK to me, though I have a few observations. Regarding the presentation format of NID and L64 RRs, is the uncompressed NNNN:NNNN:NNNN:NNNN format going to be standard throughout ILNP? I couldn't find any mention of it in draft-irtf-rrg-ilnp-arch. The DNS master file presentation format should be the same as the usual syntax in other contexts. > The CNAME record is closest conceptually to an LP > record, but a CNAME is a node name referral scheme, > while the LP record is indicating that the given node > has the same routing prefix as some other domain name, > but does not necessarily have any other values that are > the same. Actually the RT "route through" resource record [RFC1183] is exactly the same syntax and almost exactly the same semantics as the LP record. The only difference I can see is which resource records the querier expects to find at the target name, and the corresponding additional section processing. That might be enough to justify the new RR type. There are some textual problems with the specification of the LP RDATA: the text describing the presentation format of the target domain name actually describes the RDATA wire format. Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Biscay: Variable 3, becoming southeasterly 4 or 5 later. Slight or moderate, occasionally rough later. Occasional rain. Moderate or good. From fanf2@hermes.cam.ac.uk Sun Jun 17 10:01:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4294321F85FB for ; Sun, 17 Jun 2012 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8dUrkcghDGH for ; Sun, 17 Jun 2012 10:01:07 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49F21F85CD for ; Sun, 17 Jun 2012 10:01:07 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35226) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SgIqW-0004D4-DV (Exim 4.72) (return-path ); Sun, 17 Jun 2012 18:01:04 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SgIqW-0000EF-33 (Exim 4.67) (return-path ); Sun, 17 Jun 2012 18:01:04 +0100 Date: Sun, 17 Jun 2012 18:01:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dnsext@ietf.org, teacherdddd@yahoo.com.cn, diaoyp@yahoo.com, 644247110@qq.com Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 17:01:08 -0000 So this "DNS Extension for Autonomous Internet" caught my eye. There are clearly a number of autonomy-related requirements that the DNS does not satisfy, such as private/internal names and ad-hoc networking. These are currently satisfied by working outside the architecture - BIND's views and multicast DNS respectively. However this draft is not about any of that. It appears to be proposing a technical workaround for dissatisfaction with ICANN's management of the DNS namespace. But it seems to me that none of this is necessary: all it is doing is shifting the namespace down a level. That is you can get a similar result by observing that an AIP network number performs the same function as a top-level domain and an AIP gateway performs the same function as a root name server. Instead of resolver search paths, AIP changes the resolution rules to deal with the difference between local names within the user's AIP network and global names in other AIP networks. So a nation-state can get unilateral autonomy within the current DNS without changing any software or protocols by: (1) Designating a TLD for this purpose (with or without the co-operation of ICANN); (2) Requiring all resolvers to configure name server addresses and a DNSSEC trust anchor for this TLD, so that it is independent of the root; (2) Requiring everyone to include the TLD in their resolver search paths, so users do not need to mention it in their domain names. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Westerly or southwesterly 4 or 5, occasionally 6 at first in south, becoming variable 3 later. Moderate or rough, becoming slight later. Occasional rain, fog patches developing. Moderate or good, occasionally very poor later. From wwwrun@rfc-editor.org Sun Jun 17 23:27:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E863011E80BF; Sun, 17 Jun 2012 23:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.397 X-Spam-Level: X-Spam-Status: No, score=-104.397 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybId1lxlWcD5; Sun, 17 Jun 2012 23:27:06 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 481DE11E80D0; Sun, 17 Jun 2012 23:27:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 042E372E0DC; Sun, 17 Jun 2012 23:26:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120618062638.042E372E0DC@rfc-editor.org> Date: Sun, 17 Jun 2012 23:26:38 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6672 on DNAME Redirection in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 06:27:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6672 Title: DNAME Redirection in the DNS Author: S. Rose, W. Wijngaards Status: Standards Track Stream: IETF Date: June 2012 Mailbox: scott.rose@nist.gov, wouter@nlnetlabs.nl Pages: 22 Characters: 45704 Obsoletes: RFC2672 Updates: RFC3363 I-D Tag: draft-ietf-dnsext-rfc2672bis-dname-26.txt URL: http://www.rfc-editor.org/rfc/rfc6672.txt The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ondrej.sury@nic.cz Mon Jun 18 05:58:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733AC21F862F for ; Mon, 18 Jun 2012 05:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAZnRM7J3qzo for ; Mon, 18 Jun 2012 05:58:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B152121F8565 for ; Mon, 18 Jun 2012 05:58:43 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:f52d:e45c:9bff:bc58] (unknown [IPv6:2001:1488:ac14:1400:f52d:e45c:9bff:bc58]) by mail.nic.cz (Postfix) with ESMTPSA id 991491403D3; Mon, 18 Jun 2012 14:58:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340024311; bh=Vo02djPvXp7aKw0ZKnEEypL8d7Bey+5qt+cXFD4yuK0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oNn8ZtMjOrGyVg/GbKTjf+GWowQOtiSBwH+/7MzGxIgpvSR9ML0ngtCyJquUXB9R6 3MADWu+epeBqxEv4USU+BfTzPu4yYR7RjB2xPafrji9DDcALGSTGxjNpBSoTtobgGo zbFP/3yw6Rx9PWuqhJYNVQjmBtRtvze3nWyQY54w= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Mon, 18 Jun 2012 14:58:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 12:58:44 -0000 Hi, thanks Tony for pointing that out... On 17. 6. 2012, at 19:01, Tony Finch wrote: > So this "DNS Extension for Autonomous Internet" caught my eye. There = are > clearly a number of autonomy-related requirements that the DNS does = not > satisfy, such as private/internal names and ad-hoc networking. These = are > currently satisfied by working outside the architecture - BIND's views = and > multicast DNS respectively. >=20 > However this draft is not about any of that. It appears to be = proposing a > technical workaround for dissatisfaction with ICANN's management of = the > DNS namespace. I am not so sure about the motivations, but I see this draft as = dangerous precedent. Unified DNS tree was and is an important building block of = the Internet and standardizing DNS-split would mean the end of the Internet as we know it. > But it seems to me that none of this is necessary: all it is doing is = shifting the namespace down a level. Exactly. And then it would be just a mess - every country would create = it's own Internet. > That is you can get a similar result [...] using existing = technologies. +1 not that I promote the usage of existing tools for Internet censorship, but at least those are just tools, and not the justification to split the Internet. Last, but not least, we (IETF) should produce technical documents and not political. This is quite nice example of a document which (in my view) puts priorities of national states over the openness and overall compatibility of the Internet. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From bortzmeyer@nic.fr Mon Jun 18 06:13:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0721F8565 for ; Mon, 18 Jun 2012 06:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.749 X-Spam-Level: X-Spam-Status: No, score=-98.749 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPzuUhmKssHK for ; Mon, 18 Jun 2012 06:13:34 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 10BBF21F855E for ; Mon, 18 Jun 2012 06:13:33 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2264E280541; Mon, 18 Jun 2012 15:13:08 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 1C4F52804E4; Mon, 18 Jun 2012 15:13:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 1990B4C0082; Mon, 18 Jun 2012 15:12:38 +0200 (CEST) Date: Mon, 18 Jun 2012 15:12:38 +0200 From: Stephane Bortzmeyer To: Ond?ej =?iso-8859-1?Q?Sur=FD?= Message-ID: <20120618131237.GA5032@nic.fr> References:

MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:13:35 -0000 On Mon, Jun 18, 2012 at 02:58:31PM +0200, Ond?ej Sur� wrote a message of 35 lines which said: > Unified DNS tree was and is an important building block of the > Internet and standardizing DNS-split would mean the end of the > Internet as we know it. The I-D does not split the DNS at all. It plays with words by pretending it will allow several roots but this is not true. Instead, it creates a super-root (the one which will allocate the AIPs, the .A and .B in the examples) and therefore just displaces the (real) problems to the super-root. This is what the vast majority of "several roots" systems do: create a new root but do not call it a root. Newspeak at its best... From ebw@abenaki.wabanaki.net Mon Jun 18 06:26:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53CC21F85D0 for ; Mon, 18 Jun 2012 06:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3AR4y0NlSZc for ; Mon, 18 Jun 2012 06:26:59 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2820821F85CE for ; Mon, 18 Jun 2012 06:26:59 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5IAI5Q6011980 for ; Mon, 18 Jun 2012 06:18:05 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDF2C9D.4010608@abenaki.wabanaki.net> Date: Mon, 18 Jun 2012 09:26:53 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:26:59 -0000 On 6/17/12 1:01 PM, Tony Finch wrote: > It appears to be proposing a > technical workaround for dissatisfaction with ICANN's management of the > DNS namespace. cnnic's ns constellation was illuminated in 2001. the published zone contained several non-ascii labels -- the better part of a decade before any non-ascii labels were added to the zone published by corporations in marina del rey and reston, with the permission of a government. my point being that (a) the engineering is not novel, though the draft in this context is, and (b) purpose may include permitting resources, e.g., han script, not just denial of resources, e.g., content scope limitations. -e From ondrej.sury@nic.cz Mon Jun 18 06:29:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC63721F85E1 for ; Mon, 18 Jun 2012 06:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITfh74F9rmw9 for ; Mon, 18 Jun 2012 06:29:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF021F85D0 for ; Mon, 18 Jun 2012 06:29:14 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:f52d:e45c:9bff:bc58] (unknown [IPv6:2001:1488:ac14:1400:f52d:e45c:9bff:bc58]) by mail.nic.cz (Postfix) with ESMTPSA id 570B413FBBF; Mon, 18 Jun 2012 15:29:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340026153; bh=SYkfKVZIk9CsAZm7XsgXSKb/YlZqsW+SygzhQ5jRTgY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=makZ6gTtoeg+aXpe0AtmKQ0Gaw+ADf8YdHuGCRzWWlx/STFZxOI4lzScZspKAjBz1 RDqQXVikwBGCAxqUAceFGiq7+URg/dXxAr66zqKTfZWl3bygkT3LmNqZOz13B3ESIe mouOczCSx9+tOx6fesCHtbZD0ls97/DkRoHJ03yY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120618131237.GA5032@nic.fr> Date: Mon, 18 Jun 2012 15:29:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References:

<20120618131237.GA5032@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:29:16 -0000 On 18. 6. 2012, at 15:12, Stephane Bortzmeyer wrote: > On Mon, Jun 18, 2012 at 02:58:31PM +0200, > Ond?ej Sur=C3=BD wrote=20 > a message of 35 lines which said: >=20 >> Unified DNS tree was and is an important building block of the >> Internet and standardizing DNS-split would mean the end of the >> Internet as we know it. >=20 > The I-D does not split the DNS at all. It plays with words by > pretending it will allow several roots but this is not true. Instead, > it creates a super-root (the one which will allocate the AIPs, the .A > and .B in the examples) and therefore just displaces the (real) > problems to the super-root. Well, yes and no. It's something in between. If you are in '.A' AIP, you will not have to type .A at the end of your query, so gov.cn will work as is without '.A'. Only if you want to go to 'unapproved' site in .B tree you will have to type 'encrypted.google.com.you-will-be-arrested' into your browser URL bar. > This is what the vast majority of "several roots" systems do: create a > new root but do not call it a root. Newspeak at its best... Yup, I agree. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ogud@ogud.com Mon Jun 18 10:27:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CDF21F86C4 for ; Mon, 18 Jun 2012 10:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drvEjtQYE8aF for ; Mon, 18 Jun 2012 10:27:37 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3EC21F85DA for ; Mon, 18 Jun 2012 10:27:37 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q5IHRWF2035337 for ; Mon, 18 Jun 2012 13:27:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FDF6503.2070409@ogud.com> Date: Mon, 18 Jun 2012 13:27:31 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120618062638.042E372E0DC@rfc-editor.org> In-Reply-To: <20120618062638.042E372E0DC@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] RFC 6672 on DNAME Redirection in the DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:27:38 -0000 Scott and Wouter Thank you for your diligence in getting this document done. Olafur & Andrew On 18/06/2012 02:26, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6672 > > Title: DNAME Redirection in the DNS > Author: S. Rose, W. Wijngaards > Status: Standards Track > Stream: IETF > Date: June 2012 > Mailbox: scott.rose@nist.gov, > wouter@nlnetlabs.nl > Pages: 22 > Characters: 45704 > Obsoletes: RFC2672 > Updates: RFC3363 > > I-D Tag: draft-ietf-dnsext-rfc2672bis-dname-26.txt > > URL: http://www.rfc-editor.org/rfc/rfc6672.txt > > The DNAME record provides redirection for a subtree of the domain > name tree in the DNS. That is, all names that end with a particular > suffix are redirected to another part of the DNS. This document > obsoletes the original specification in RFC 2672 as well as updates > the document on representing IPv6 addresses in DNS (RFC 3363). > [STANDARDS-TRACK] > > This document is a product of the DNS Extensions Working Group of the IETF. > > This is now a Proposed Standard Protocol. > From ajs@anvilwalrusden.com Mon Jun 18 11:02:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25421F86E5; Mon, 18 Jun 2012 11:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iETHnQYbwy9L; Mon, 18 Jun 2012 11:02:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AE42021F86E0; Mon, 18 Jun 2012 11:02:10 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7437D1ECB41D; Mon, 18 Jun 2012 18:02:09 +0000 (UTC) Date: Mon, 18 Jun 2012 14:02:07 -0400 From: Andrew Sullivan To: iesg-secretary@ietf.org, rdroms.ietf@gmail.com Message-ID: <20120618180207.GM32683@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-update-03 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:02:11 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Ralph, This is a publication request for draft-ietf-dnsext-dnssec-registry-update-03.txt. The completed standard write-up template is attached. Upon sending this mail, I will update the document status in the datatracker. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=proto-20120618 Document shepherd write-up for draft-ietf-dnsext-dnssec-registry-update-03 Template version 2012-02-24 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. Working Group Summary The changes this draft makes were originally bound up with some changes from a previous WG draft that was not published. Some of the WG and, particularly, the IESG objected to the way that draft altered the registry; this draft and another one were the results. This draft is not bound up with the other draft, and makes the uncontroversial changes to the registry. Document Quality This draft makes no changes to any protocol, but cleans up a number of errors and omissions in the relevant registry. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Sullivan is the Document Shepherd. Ralph Droms is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document thoroughly, comparing it to the existing registry and following the references. All appears to be in order to him. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been few posts specifically about this draft. The predecessor draft was reviewed adequately; the WG was consulted on breaking that draft into two (of which this forms one constituent part); and this resulting draft is consistent with the negotiations with the IESG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The IESG should ascertain that this draft responds to the objections raised against draft-ietf-dnsext-dnssec-registry-fixes-08 where they are relevant to the content of this draft. As far as the shepherd understands things, it does, but it would be best if IESG members confirmed for themselves. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has repeatedly lamented the state of the registry; this document fixes it. The document has attracted a tiny number of comments, but the shepherd believes this is mostly because the predecessor draft had already addressed all the relevant issues. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Checked; no issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). In effect, the entire document is instructions to IANA. The registry is clearly identified. The draft alters an existing registry and does not create a new one. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. --+QahgC5+KEYLbs62-- From ajs@anvilwalrusden.com Mon Jun 18 11:04:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537AE21F86EA; Mon, 18 Jun 2012 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6efSji-Q30wC; Mon, 18 Jun 2012 11:04:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1021F86E0; Mon, 18 Jun 2012 11:04:38 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 386F21ECB41D; Mon, 18 Jun 2012 18:04:37 +0000 (UTC) Date: Mon, 18 Jun 2012 14:04:35 -0400 From: Andrew Sullivan To: iesg-secretary@ietf.org, rdroms.ietf@gmail.com Message-ID: <20120618180435.GN32683@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: [dnsext] Publication request: draft-ietf-dnsext-dnssec-algo-imp-status-03 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:04:39 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Ralph, This is a request for publication of draft-ietf-dnsext-dnssec-algo-imp-status-03 as a BCP. The completed standard write-up template is attached. After sending this note, I'll update the datatracker status for the draft. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=proto-20120618 Submission write-up for draft-ietf-dnsext-dnssec-algo-imp-status-03. Template date 2012-02-24 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? BCP (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. The document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. Working Group Summary The intended effect of this draft was originally captured in draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and controversial use of the IANA registry. That approach was too controversial, and so the WG split the document into two parts. This draft is one of them. The present approach was far less controversial than the previous one, and nobody has raised any objection to the current text. Document Quality The draft does not specify a protocol of any kind, but it does make a recommendation in favour of some algorithms that are so far not widely deployed. The discussion of dnssec-registry-fixes led to the approach instantiated in this draft. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document for content, to make sure that it was in keeping with the WG's consensus, to ensure that its references were correct, and to ensure that it addressed previous objections to the approach adopted in dnssec-registry-fixes. The document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There was adequate discussion of the draft, and a significant amount of it had to do with whether a particular word was the right one. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, except that the IESG should confirm that the approach in the draft meets its objections to the predecessor draft. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The IESG should confirm that the approach in the draft meets its objections to the predecessor draft. Otherwise, none. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There appear to be no objections. The WG has previously lamented the problem that figuring out what is a conforming DNSSEC validator or server implementation has been hard because of the lack this draft seeks to address. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits all pass. The nits tool says that two updates are missing from the header, but I can see them. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This draft is intended to update a number of others. They are all listed. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not actually change or create any IANA registry, but it requests addition of itself as a reference from the relevant registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A. --TRYliJ5NKNqkz5bu-- From fred@cisco.com Mon Jun 18 13:17:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B168921F854A for ; Mon, 18 Jun 2012 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.156 X-Spam-Level: X-Spam-Status: No, score=-108.156 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PabqL+vsasRd for ; Mon, 18 Jun 2012 13:17:35 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93421F8549 for ; Mon, 18 Jun 2012 13:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4228; q=dns/txt; s=iport; t=1340050655; x=1341260255; h=mime-version:subject:from:date:cc:message-id:to: content-transfer-encoding; bh=icZbRm09ZulVi0ly4KuBNqcommgtWvTDb5sGiDADtsc=; b=UzHVkx+iFIjtHqK7qA/WRs037Gf1l0v3H975feDNTwZNolPdQdSkOWc1 +aaEupsqurxTF4qOvhj1Lgklwd4yBMQnhVdUhbEjkKLkas/eLbPNaFdfi PF4sueY7Hz/ybMZhKaCaTTKEgbtrMSa508xTkz9nXW9TsmAydNFHJh0wS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskhAGiM30+rRDoI/2dsb2JhbABFtEKBLIEHgjEBJw8wgXOFb4F5mGaPE5Bbi1GFQWADiEKMYoVUiEOBZoMAgT8 X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="49318129" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Jun 2012 20:17:34 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5IKHXAj028110; Mon, 18 Jun 2012 20:17:33 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 18 Jun 2012 13:17:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 18 Jun 2012 13:17:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Mon, 18 Jun 2012 13:17:28 -0700 Message-Id: To: draft-diao-aip-dns@tools.ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Jun 2012 13:20:25 -0700 Cc: dnsext@ietf.org Subject: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:17:36 -0000 This is a resend, copying the right list. I'm reading draft-diao-aip-dns, and wonder what the context is. Is this = related to the BRICI proposal in WCIT, for support for a DNS root = modeled on the International Calling Code structure of the telephone = system? My concern is for the possibility of disruption to Internet = communications. If a country (or for that matter a business that simply = decides to sell access to its own autonomous root) acts autonomously and = unilaterally to add a TLD, other countries/services may or may not know = about it, and the names may therefore not be usable in any context other = than the country/service itself. If DNS resolution of names that are not = from the country/service in question are forced to channel through the = autonomous root, there are "interesting" questions of scale. Comments on the paper itself: The Introduction opens with the sentence Internet Domain Name System (DNS) distributes domain name and IP =20= address for the host on the Internet. DNS automatically translates =20= the domain name into IP address when user accesses Internet using =20= domain name.=20 I would dispute that. The DNS enables a client to obtain a resource = record from a name service; the resource record might be for an IPv4 or = IPv6 address (A/AAAA), for the name of one or more mail servers (MX), an = encryption/signature key, or a variety of other types of information. In section 3.2, if I understand the document correctly, the document = proposes to use recursive DNS access between AIPs. I have no problem = with recursive translation; it is defined and works now. However, it = would appear that this recursive translation happens between AIP DNS = roots, as opposed to happening from a DNS server closer to the original = request. I think that is likely to have serious scaling issues. One general comment on sentence structure: in English, it is considered = poor form to start a sentence with "And". For example And any IP node's external domain =20 name is consist of its internal domain name and its AIP network =20= default domain name suffix. =20 should read Any IP node's external domain =20 name consists of its internal domain name and its AIP network =20 default domain name suffix.=20 While the specific point is a nit, I see it frequently in the paper. I'm not sure I understand rule 3 in section 2.2. If, for example, I am = in a Chinese AIP and want to access www.example.com, but I want to get = to the one that would be accessible from Brazil, do I access = "www.example.com", "www.example.com.ex", www.example.com.br.ex", or = something else? Is there any reason to believe that the resource record = for www.example.com within the AIP is the same as the one for the same = name in some other AIP? I worry about that, as much as anything, because = international business and communication depends on a common = understanding of resource records; if a vendor in country A wants to = make a product or service available to a potential customer in country B = (or for that matter in all countries), it gives one URI/URL to all of = them and they all have access to it. If there is significant confusion = at this level, sending for example requests intended for Google to = Baidu, it will have a significant and negative effect on international = business and communications. That not only doesn't bode well for the = Internet as an international communication vehicle, it portends poor = economic results for the countries that deploy autonomous internets. Last time China proposed this (October 2000), John Klensin and I flew to = Beijing to discuss it with Professor Qian Hua-lin. He agreed that the = economic importance of international trade far outweighed the value of = having an autonomous naming system... Could you comment on the proposal, explaining in more detail what you = have in mind, and how (a) the service remains scalable, and (b) the = service supports the international objectives of business interests that = use it? From d3e3e3@gmail.com Mon Jun 18 16:19:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9B11E80D5 for ; Mon, 18 Jun 2012 16:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.549 X-Spam-Level: X-Spam-Status: No, score=-101.549 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbrNPGalf5FF for ; Mon, 18 Jun 2012 16:19:39 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4B511E80A0 for ; Mon, 18 Jun 2012 16:19:39 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4594133ghb.31 for ; Mon, 18 Jun 2012 16:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3jHOz4hEkDSh0LL9aR6aVnsMtjlQY42xghEyijusKV0=; b=zfC+v2PX4z18DRzounA57mC7gi+2h8X7wADlUoiJ1ZEy5ZTl1Grj/lCVP/uUDAUU0F 1fIn/Fplb4bEDILP3+k+8lNysNi4v1mwZs4jsiCPGlIQDmjW81eQZ61L6crLDSv87mjn PgPkP8BdFW3EnaGwc5jcUksfR5ieFmeVfp813wNJbLGcX2Wtu56ul2T7nRwKK23XoE22 FBTg+ytE0Yp4KwqBjsf1RbGBYXdi5+vKxUEGZXthRVQUI/53yotVh/pV3xMVu/pNWY1G eiyRZiTFbJO4DBlt4puzHVnJP/xRasGtBCQz5tyD4uidheWjQjbR0Sw5ovAIwsIW4Xb3 L1CA== Received: by 10.50.100.129 with SMTP id ey1mr9931383igb.35.1340061578158; Mon, 18 Jun 2012 16:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 18 Jun 2012 16:19:17 -0700 (PDT) In-Reply-To: References:

<20120618131237.GA5032@nic.fr> From: Donald Eastlake Date: Mon, 18 Jun 2012 19:19:17 -0400 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 23:19:40 -0000 If you want multiple sets of roots within the DNS protocol, you just use CLASS. "Countries" have 3 digit UN country numbers as well as alpha codes, so you could assign a block of 1000 CLASSes for this purpose. Then all you need are B/C/DNAME RRs that include a target CLASS as well as a domain name... :-) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Jun 18, 2012 at 9:29 AM, Ond=F8ej Sur=FD wrote= : > > On 18. 6. 2012, at 15:12, Stephane Bortzmeyer wrote: > >> On Mon, Jun 18, 2012 at 02:58:31PM +0200, >> Ond?ej Sur=FD wrote >> a message of 35 lines which said: >> >>> Unified DNS tree was and is an important building block of the >>> Internet and standardizing DNS-split would mean the end of the >>> Internet as we know it. >> >> The I-D does not split the DNS at all. It plays with words by >> pretending it will allow several roots but this is not true. Instead, >> it creates a super-root (the one which will allocate the AIPs, the .A >> and .B in the examples) and therefore just displaces the (real) >> problems to the super-root. > > Well, yes and no. =A0It's something in between. > > If you are in '.A' AIP, you will not have to type .A at the end of your > query, so gov.cn will work as is without '.A'. =A0Only if you want to go > to 'unapproved' site in .B tree you will have to type > 'encrypted.google.com.you-will-be-arrested' into your browser URL bar. > >> This is what the vast majority of "several roots" systems do: create a >> new root but do not call it a root. Newspeak at its best... > > > Yup, I agree. > > O. > -- > =A0Ond=F8ej Sur=FD -- Chief Science Officer > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From rdroms@cisco.com Mon Jun 18 16:50:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CC11E809A for ; Mon, 18 Jun 2012 16:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlJep5aq6eLA for ; Mon, 18 Jun 2012 16:50:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09B11E8079 for ; Mon, 18 Jun 2012 16:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1960; q=dns/txt; s=iport; t=1340063418; x=1341273018; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=guOoWmbxYbgWIpUwXD6FoBu7KNVgCNJQy8xin+arRBg=; b=YjL/dkjwCl7+jA8ZB3bmg6S8hZec3E2kVIedjbRBZMq3cFfzvYj6q+7v YfwciIqWoQ4p3VYjR5+dHqBHzVDeN+zzuZJV/fg1ycm9bhu2TGB4Nn4qR XbEUgP+PgI+OzR74wWuHpKeyM74rfHRypJItCeeE/gBQI6JVsQqx0CITY 0=; X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="93600616" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2012 23:50:18 +0000 Received: from [10.86.247.186] ([10.86.247.186]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5INoGuU023043; Mon, 18 Jun 2012 23:50:16 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Ralph Droms In-Reply-To: Date: Mon, 18 Jun 2012 17:50:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <091E739B-4089-4F00-AD34-9D8B0DE06969@cisco.com> References:

<20120618131237.GA5032@nic.fr> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com, teacherdddd@yahoo.com.cn Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 23:50:19 -0000 On Jun 18, 2012, at 7:29 AM 6/18/12, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 18. 6. 2012, at 15:12, Stephane Bortzmeyer wrote: >=20 >> On Mon, Jun 18, 2012 at 02:58:31PM +0200, >> Ond?ej Sur=C3=BD wrote=20 >> a message of 35 lines which said: >>=20 >>> Unified DNS tree was and is an important building block of the >>> Internet and standardizing DNS-split would mean the end of the >>> Internet as we know it. >>=20 >> The I-D does not split the DNS at all. It plays with words by >> pretending it will allow several roots but this is not true. Instead, >> it creates a super-root (the one which will allocate the AIPs, the .A >> and .B in the examples) and therefore just displaces the (real) >> problems to the super-root. >=20 > Well, yes and no. It's something in between. >=20 > If you are in '.A' AIP, you will not have to type .A at the end of = your > query, so gov.cn will work as is without '.A'. Only if you want to go > to 'unapproved' site in .B tree you will have to type > 'encrypted.google.com.you-will-be-arrested' into your browser URL bar. I also think that if you query example.com (with no .* suffix) in realm = A, you may get a different answer than if you query example.com in realm = B. - Ralph >=20 >> This is what the vast majority of "several roots" systems do: create = a >> new root but do not call it a root. Newspeak at its best... >=20 >=20 > Yup, I agree. >=20 > O. > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Mon Jun 18 17:01:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE211E80F1 for ; Mon, 18 Jun 2012 17:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52bnSdpOmIQG for ; Mon, 18 Jun 2012 17:01:18 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0427511E80F0 for ; Mon, 18 Jun 2012 17:01:18 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4762F5F98E6; Tue, 19 Jun 2012 00:01:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3429:664b:266e:51bf]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2DE30216C33; Tue, 19 Jun 2012 00:01:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 13AE921B8A3F; Tue, 19 Jun 2012 10:00:40 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References:

In-reply-to: Your message of "Mon, 18 Jun 2012 14:58:31 +0200." Date: Tue, 19 Jun 2012 10:00:40 +1000 Message-Id: <20120619000041.13AE921B8A3F@drugs.dv.isc.org> Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 00:01:19 -0000 In message , =?utf-8?Q?Ond=C5=99ej _Sur=C3=BD?= writes: > Hi, > > thanks Tony for pointing that out... > > On 17. 6. 2012, at 19:01, Tony Finch wrote: > > > So this "DNS Extension for Autonomous Internet" caught my eye. There are > > clearly a number of autonomy-related requirements that the DNS does not > > satisfy, such as private/internal names and ad-hoc networking. These are > > currently satisfied by working outside the architecture - BIND's views > and > > multicast DNS respectively. > > > > However this draft is not about any of that. It appears to be proposing > a > > technical workaround for dissatisfaction with ICANN's management of the > > DNS namespace. > > I am not so sure about the motivations, but I see this draft as dangerous > precedent. Unified DNS tree was and is an important building block of the > Internet and standardizing DNS-split would mean the end of the Internet > as we know it. The same entered name should get to the same resource even if the resource does not resolve everywhere. This doesn't meet this property. Additionally RFC 1535 shows why this approach is bad. This would codify the flaw indentified in RFC 1535. Classic split DNS is additive with additional names, address, etc. added to the public view to create the private view. > > But it seems to me that none of this is necessary: all it is doing is > shifting the namespace down a level. > > > Exactly. And then it would be just a mess - every country would create > it's own Internet. > > > That is you can get a similar result [...] using existing technologies. > > > +1 > > not that I promote the usage of existing tools for Internet censorship, > but at least those are just tools, and not the justification to split > the Internet. > > Last, but not least, we (IETF) should produce technical documents > and not political. This is quite nice example of a document which > (in my view) puts priorities of national states over the openness > and overall compatibility of the Internet. > > O. > -- > Ondřej Surý -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Mon Jun 18 17:54:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804821F85F7 for ; Mon, 18 Jun 2012 17:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.615 X-Spam-Level: X-Spam-Status: No, score=-105.615 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATyxELH6pYkf for ; Mon, 18 Jun 2012 17:54:04 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C388C21F85F6 for ; Mon, 18 Jun 2012 17:54:04 -0700 (PDT) Received: from [5.5.8.10] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 94D181B402E5; Mon, 18 Jun 2012 20:54:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: Date: Mon, 18 Jun 2012 20:54:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com, teacherdddd@yahoo.com.cn Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 00:54:06 -0000 On Jun 18, 2012, at 8:58 AM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > thanks Tony for pointing that out... >=20 > On 17. 6. 2012, at 19:01, Tony Finch wrote: >=20 >> So this "DNS Extension for Autonomous Internet" caught my eye. There = are >> clearly a number of autonomy-related requirements that the DNS does = not >> satisfy, such as private/internal names and ad-hoc networking. These = are >> currently satisfied by working outside the architecture - BIND's = views and >> multicast DNS respectively. >>=20 >> However this draft is not about any of that. It appears to be = proposing a >> technical workaround for dissatisfaction with ICANN's management of = the >> DNS namespace. >=20 > I am not so sure about the motivations, but I see this draft as = dangerous > precedent. Unified DNS tree was and is an important building block of = the > Internet and standardizing DNS-split would mean the end of the = Internet > as we know it. >=20 >> But it seems to me that none of this is necessary: all it is doing is = shifting the namespace down a level. >=20 >=20 > Exactly. And then it would be just a mess - every country would = create it's own Internet. >=20 >> That is you can get a similar result [...] using existing = technologies. >=20 >=20 > +1 >=20 > not that I promote the usage of existing tools for Internet = censorship, > but at least those are just tools, and not the justification to split > the Internet. >=20 > Last, but not least, we (IETF) should produce technical documents > and not political. This is quite nice example of a document which > (in my view) puts priorities of national states over the openness > and overall compatibility of the Internet. Hear hear=E2=80=A6. There are a large number of major issues with the document (apart from = legibility), but the added complexity and fragility for someone's = nationalistic desires are not a reasonable tradeoff. I was also muchly entertained by the Security Considerations and IANA = Considerations bits -- wheee, lets bypass the existing (flawed) process = and gets our own string by publishing a doc=E2=80=A6 W >=20 > O. > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=20 With Feudalism, it's your Count that votes. From ajs@anvilwalrusden.com Mon Jun 18 19:12:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB70C11E80EF; Mon, 18 Jun 2012 19:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVJyys1TpQ9T; Mon, 18 Jun 2012 19:12:24 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D897C11E80D7; Mon, 18 Jun 2012 19:12:23 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 53BE91ECB41D; Tue, 19 Jun 2012 02:12:13 +0000 (UTC) Date: Mon, 18 Jun 2012 22:12:11 -0400 From: Andrew Sullivan To: "Richard L. Barnes" , dnsext@ietf.org Message-ID: <20120619021211.GI32683@crankycanuck.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-dnsext-dnssec-bis-updates@tools.ietf.org, IESG , ietf@ietf.org Subject: Re: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:12:24 -0000 Hi, I'm the shepherd for this draft. Thanks for the review. Some follow-up inline. On Fri, May 25, 2012 at 05:02:28PM -0400, Richard L. Barnes wrote: > > MAJOR: > > 4.1. > It's not clear what the threat model is that this section is > designed to address. If the zone operator is malicious, then it can > simulate the necessary zone cut and still prove the non-existence of > records in the child zone. The problem here is not a malicious parent operator, but "an NSEC or NSEC3 RR from an ancestor zone". In the original specification, an attacker could use such an RR to prove the non-existence of some name in a subordinate zone. That was the problem. (Remember, in DNS there is a good chance that you are not talking to an authoritative server.) If you have suggestions on ways to make that clearer, it'd be welcome. The editors tried to come up with compact examples that would be anything other than mystifying, and were unsuccessful. > 5.10. > I find the recommendation of the "Accept Any Success" policy > troubling. It deals very poorly with compromise (and other > roll-over scenarios): Suppose there are two trust anchors, one for > example.com and one for child.example.com. If the private key > corresponding to the TA for child.example.com is compromised, but > the validator continues to trust it, this negates the benefit > provided by the parent (example.com) facilitating a rollover. > Suggest an alternative policy, "Highest Signer": Out of the set of > keys configured as TAs, the validator only uses a key as a TA (for > purposes of validation) if there does not exist a DNSSEC path from > it to any other TA. This policy seems like more work to enforce > (because you have to do more backward chaining), but ISTM that the > validator should have the necessary DNSSEC records anyway, so it's > just a matter a couple of quick checks. First, the Working Group debated this matter at considerable length, several times. The Accept Any Success policy provides greater robustness in the face of configuration errors, and is more likely to lead to continued resolution. We believe, based on experience so far, that such configuration errors are vastly more likely than key compromise. If we are to reopen this, we will need to go back to the WG again. Note that Appendix C does discuss other options and 5.10 explicitly suggests that this be configurable; but, because the biggest problem we have is resolution failure in the face of mucked up configurations, the consensus was that Accept Any Success was the best default. That could, of course, change in future, at which time an update to the document would be advisable. The suggestion for "Highest Signer" is interesting but has never to my knowledge been previously mooted in relation to this draft. I therefore think that including it in particular would require some review. I don't know of any implementation that currently uses that approach, either (but since there are vast gaps in my knowledge even of what's on my desk, it wouldn't surprise me to learn that there were some). Do you know of any? If not, it seems to me that it would be a good idea to have some fielded experience with the approach before recommending it as default. It's an intriguing idea, however, and seems to me to be worth pursuing. I'm just not sure it should be in this draft. I personally think it would be premature to recommend it as default, but if you take your position very firmly I am prepared to take the question up with the Working Group. Thanks again for the review. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@crankycanuck.ca Mon Jun 18 19:30:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053B621F85AD; Mon, 18 Jun 2012 19:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMtWnl9y3eOQ; Mon, 18 Jun 2012 19:30:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2270D21F85A5; Mon, 18 Jun 2012 19:30:38 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D34691ECB41D; Tue, 19 Jun 2012 02:30:36 +0000 (UTC) Date: Mon, 18 Jun 2012 22:30:34 -0400 From: Andrew Sullivan To: S Moonesamy Message-ID: <20120619023034.GJ32683@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: iesg@ietf.org, draft-ietf-dnsext-dnssec-bis-updates.all@tools.ietf.org, apps-discuss@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:30:39 -0000 Hi, I'm the shepherd for this document. Thanks for the review. Some questions and comments inline. On Tue, May 22, 2012 at 10:12:27AM -0700, S Moonesamy wrote: > Summary: This document is not ready for publication as a Proposed Standard. > > The proposal seems targeted at implementers who are fully conversant > with the ins and outs of DNSSEC. Although the proposal is > well-written, it lacks clarity as to what is being changed in the > "DNSSECbis document set". It may end up being more confusing. To whom would it be confusing? The draft is indeed aimed at implementers of DNSSEC (that is, people putting signing and validation into code), and not at users of DNSSEC. I'm also not sure about which places are not clear about what they're changing. Some things are simply facts that have become clear about the way the protocol works, but places where the actual text of the original documents is either added to or altered are, as far as I know, marked. Could you give an example of things you think aren't clear as to what they have changed? > There was an announcement that the DNSEXT WG would be shut down. > The rush to publish these clarifications raises questions about > whether the DNSSECbis documents will ever be advanced in the near > future from Proposed Standard to Internet Standard. It is hard to see how there is a rush here. The earliest version of this draft was submitted in 2005. I know things have slowed down around the IETF, but I can't think of seven years as a rush. > > "DNSSECbis" seems more like an internal IETF term to identify the > document set. RFC 4033, for example, does not have any mention of > "DNSSECbis". I suggest using "DNSSEC protocol document set" and > amending the title accordingly. This view seems to be shared by others. I think we can change the term to "DNSSEC" and, on first reference, say "(sometimes known as DNSSECbis)" in order to make clear that the document is not referring to the earlier incarnation. > In Section 2.1: > > "Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- > SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) > signal that a zone MAY be using NSEC3, rather than NSEC. The zone > MAY be using either and validators supporting these algorithms MUST > support both NSEC3 and NSEC responses." > > It is not clear from the above text which parts of RFC 5155 is being > modified. 5155 isn't being modified, but the class of things we call DNSSEC is: this section is there to tell people that NSSEC3 isn't really optional, because if you don't implement it you won't be able to validate .com, .net, or .org to name but three relevant zones. That's supposed to be clear from the first paragraph; is it not? > In Section 3.1: > > "Section 4.7 of RFC4035 permits security-aware resolvers to implement > a BAD cache. Because of scaling concerns not discussed in this > document, that guidance has changed: security-aware resolvers SHOULD > implement a BAD cache as described in RFC4035." > > From Section 4.7 of RFC 4035: > > "To prevent such unnecessary DNS traffic, security-aware resolvers MAY > cache data with invalid signatures, with some restrictions." > > If I understood the text from this draft, the "MAY" is being changed > into a recommendation. In which cases would it better not to follow > the recommendation? There aren't any, but we can't practically require it because under memory constraints a cache is going to be emptied anyway. > In Section 4.1: > > "In particular, the algorithm as presented would incorrectly allow > an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence > of RRs in the child zone." > > Where is ancestor zone defined? That's a good point. I don't know of anywhere, but I'm not sure this document is an appropriate place to define it. Since the DNS is a tree structure, "ancestor" has the same meaning it would for other tree structures. I think it would be a very bad idea to add definitions of this sort to this document, because the term applies to all of the DNS and not just to DNSSEC. The DNS RFCs are hard enough to navigate as it is. > "Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- > existence of any RRs below that zone cut, which include all RRs at > that (original) owner name other than DS RRs, and all RRs below that > owner name regardless of type." > > It is not clear what is being clarified. The problem that is described in the paragraph immediately before this paragraph -- the one you quoted just above. Richard Barnes also complained about not understanding this section, so I acknowledge there's a problem here, but I'm not sure how to fix it. What is unclear to you? > In the Introduction Section: > > The IETF is now using two maturity levels. "Draft Standard" has been > changed to "Internet Standard" Good catch, thanks. I suggest "when advancing the DNSSEC documents along the standards track". How's that? > In Section 6.3: > > This section discusses about errors in the examples in RFC 4035. As > a stylistic comment, it is clearer to the reader if he/she could see > the actual examples with the corrections made. I think the intention was that the reader would have the original open along with this document when reading. How would you like it rewritten? Best, A -- Andrew Sullivan ajs@crankycanuck.ca From ajs@anvilwalrusden.com Mon Jun 18 19:49:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DF211E80A3 for ; Mon, 18 Jun 2012 19:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nXy8UGU+XQ6 for ; Mon, 18 Jun 2012 19:49:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 39AE911E8080 for ; Mon, 18 Jun 2012 19:49:48 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 27B2D1ECB41D; Tue, 19 Jun 2012 02:49:47 +0000 (UTC) Date: Mon, 18 Jun 2012 22:49:45 -0400 From: Andrew Sullivan To: Stephane Bortzmeyer Message-ID: <20120619024945.GL32683@mail.yitter.info> References:

<20120618131237.GA5032@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120618131237.GA5032@nic.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:49:48 -0000 On Mon, Jun 18, 2012 at 03:12:38PM +0200, Stephane Bortzmeyer wrote: > The I-D does not split the DNS at all. It plays with words by > pretending it will allow several roots but this is not true. Instead, > it creates a super-root (the one which will allocate the AIPs, the .A > and .B in the examples) and therefore just displaces the (real) > problems to the super-root. I completely agree, and I think that issue is the fundamental problem with the draft. We do not need a single root for some political or organizational reason; lots of things get along without that. But the DNS is a tree in the mathematical sense. It is _incoherent_ to say that you can have multiple roots in such a tree. If you have multiple roots, that just means that you're not yet at the root, properly described. You're merely at an apex. Some of the draft is hard to understand because its prose needs work; that is a mere matter of editing. But a portion of the draft will never be possible to understand, because it is trying to hide the fundamental confusion at its core. A muddled idea can never be clear, even once it is clear how muddled the idea is. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From bortzmeyer@nic.fr Tue Jun 19 02:37:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBB921F85C7 for ; Tue, 19 Jun 2012 02:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq0NEuP639mQ for ; Tue, 19 Jun 2012 02:37:49 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 098AB21F8518 for ; Tue, 19 Jun 2012 02:37:49 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CA5E02805A0; Tue, 19 Jun 2012 11:37:26 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id C42FF28056F; Tue, 19 Jun 2012 11:37:26 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id B89534C0053; Tue, 19 Jun 2012 11:36:56 +0200 (CEST) Date: Tue, 19 Jun 2012 11:36:56 +0200 From: Stephane Bortzmeyer To: Ralph Droms Message-ID: <20120619093656.GA24383@nic.fr> References:

<20120618131237.GA5032@nic.fr> <091E739B-4089-4F00-AD34-9D8B0DE06969@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <091E739B-4089-4F00-AD34-9D8B0DE06969@cisco.com> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com, teacherdddd@yahoo.com.cn Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 09:37:49 -0000 On Mon, Jun 18, 2012 at 05:50:16PM -0600, Ralph Droms wrote a message of 56 lines which said: > I also think that if you query example.com (with no .* suffix) in > realm A, you may get a different answer than if you query > example.com in realm B. It is the exact same thing as the "search" directive in resolv.conf. When I type "ping www" at home or at work (or "ping www.lab" if you want an example with multiple labels), I ping a different machine. From rwfranks@gmail.com Tue Jun 19 08:34:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F1911E80A3 for ; Tue, 19 Jun 2012 08:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPNjaDRNNTHm for ; Tue, 19 Jun 2012 08:34:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF811E8099 for ; Tue, 19 Jun 2012 08:34:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3859624vbb.31 for ; Tue, 19 Jun 2012 08:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=EDxlfTfAkImN57Yqa1lWD9OJVDuthr0Bq1fCdTtLBfA=; b=qGYwkqmCSdZvxES/gMVqYsa1+zcaAQmNQeIZZi/y5sVIQRJN1eDZUCffUdwXIh83gK 9VE+yXUGFxOPSv4wA4kuoYlzK1/CPUxYuIWK3QJ3/vfhg8ja9RAsHc7zank/7OuVP8ph CJk5M5n5MfjmZrYZC0TKaFT42pro4gUNaqSRXbfsBTQqYk0ELmYb6iWR/Sq2ROQC0N2T UMaclVNF2kUTO+WBVl6KSI5P1QZeDY8iCRGmXzNI4/cs7BwV6wyKM0mtrFwTjPW5BI0o hx8brAlQThp9mLJKOmANxcG+E73KykzkO8Eb39VtvX44QyJiT/tbgFhSiYfoxmj6liTy zgDg== Received: by 10.52.95.139 with SMTP id dk11mr8048354vdb.12.1340120053708; Tue, 19 Jun 2012 08:34:13 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.52.38.228 with HTTP; Tue, 19 Jun 2012 08:33:53 -0700 (PDT) In-Reply-To: <4FD62E4E.4020007@ogud.com> References: <4FD62E4E.4020007@ogud.com> From: Dick Franks Date: Tue, 19 Jun 2012 16:33:53 +0100 X-Google-Sender-Auth: kPu7x5boJaizzBAo1MFpaz4dwhA Message-ID: To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:34:15 -0000 Olafur, I have reviewed draft-ietf-dnsext-rfc6195bis-02 and offer the following observations: [3.1 paragraph 4] and [3.2 paragraph 4] Regexes: [A-Z][A-Z0-9\-]*[A-Z0-9] (TYPE|CLASS)(0|[1-9][0-9]*) could be simplified to: [A-Z][A-Z0-9]* (TYPE|CLASS)[0-9]* Previous RFC authors have abstained from using the hyphen when specifying RRTYPE and CLASS mnemonics. Regex 1 should constrain future authors and IANA to follow established custom and practice. The only historical exception (NSAP-PTR) lived quietly in RFC1348 and became obsolete in 1994. Regex 2, as written, fails to match unknown type and class identifiers having leading zeroes in the numeric part, which is not explicitly disallowed by RFC3597. IMHO the mnemonics CLASS and TYPE (no digits) should also be disallowed to avoid accidental ingestion of place-holders if/when any part of this process becomes automated. Dick On 11 June 2012 18:43, Olafur Gudmundsson wrote: > > > > Dear colleagues > > > > This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ J= une 28'th 2012. > > http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02 > > > > This document addresses known flaws in the RFC6195 (see appendix A). > > > > Please review the document and post a note that you have reviewed the doc= ument we need a minimum of 5 reviewers. > > > > =C2=A0 =C2=A0Olafur & Andrew > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > From rdroms@cisco.com Tue Jun 19 10:23:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793EF11E8088 for ; Tue, 19 Jun 2012 10:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxte-fg5bIdu for ; Tue, 19 Jun 2012 10:23:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C078511E80BE for ; Tue, 19 Jun 2012 10:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=886; q=dns/txt; s=iport; t=1340126589; x=1341336189; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eXtuLEn4hNCwW0+Z/GImEbu9K3tvwE08enQ5qyOM+Gs=; b=R/SeWNetcaue9+y6ffVSm408FS+O8jBnmcLlfHRI0gEazgrctTNU2r4Y /m+d6ZwV/d9h9+FsQ0ZeX3XgwZelsINr/yvBw4uogorQtoiNhHlUfZ2XL Ke9mQORGdfnLcyvgE9gPtZ2U4Gn0j7QLS5uw+fF8CVZaOqN3jkOte5mTm 0=; X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="93886013" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jun 2012 17:23:08 +0000 Received: from [10.86.253.222] ([10.86.253.222]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5JHN5OK030945; Tue, 19 Jun 2012 17:23:06 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20120619093656.GA24383@nic.fr> Date: Tue, 19 Jun 2012 11:23:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References:

<20120618131237.GA5032@nic.fr> <091E739B-4089-4F00-AD34-9D8B0DE06969@cisco.com> <20120619093656.GA24383@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com, teacherdddd@yahoo.com.cn Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:23:11 -0000 On Jun 19, 2012, at 3:36 AM 6/19/12, Stephane Bortzmeyer wrote: > On Mon, Jun 18, 2012 at 05:50:16PM -0600, > Ralph Droms wrote=20 > a message of 56 lines which said: >=20 >> I also think that if you query example.com (with no .* suffix) in >> realm A, you may get a different answer than if you query >> example.com in realm B. >=20 > It is the exact same thing as the "search" directive in > resolv.conf. When I type "ping www" at home or at work (or "ping > www.lab" if you want an example with multiple labels), I ping a > different machine. Hm. I guess the similarity extends to the observation that a user can = reconfigure to avoid the serach directive issue, and can reconfigure to = use an RDNSS in the desired "realm" (rather than, e.g., the RDNSS = provided through DHCP) to avoid the side effects of draft-diao-aip-dns. - Ralph From marka@isc.org Tue Jun 19 18:52:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5F11E80EB for ; Tue, 19 Jun 2012 18:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eEPKsDQ252k for ; Tue, 19 Jun 2012 18:52:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E111E80BA for ; Tue, 19 Jun 2012 18:52:40 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 871F5C96A2; Wed, 20 Jun 2012 01:52:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f9fd:b5da:db5b:dfdf]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DE505216C3D; Wed, 20 Jun 2012 01:52:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B33E921BE342; Wed, 20 Jun 2012 11:52:25 +1000 (EST) To: Ralph Droms From: Mark Andrews References:

<20120618131237.GA5032@nic.fr> <091E739B-4089-4F00-AD34-9D8B0DE06969@cisco.com> <20120619093656.GA24383@nic.fr> In-reply-to: Your message of "Tue, 19 Jun 2012 11:23:05 CST." Date: Wed, 20 Jun 2012 11:52:25 +1000 Message-Id: <20120620015225.B33E921BE342@drugs.dv.isc.org> Cc: teacherdddd@yahoo.com.cn, dnsext@ietf.org, 644247110@qq.com, diaoyp@yahoo.com Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 01:52:57 -0000 In message , Ralph Droms writes: > > On Jun 19, 2012, at 3:36 AM 6/19/12, Stephane Bortzmeyer wrote: > > > On Mon, Jun 18, 2012 at 05:50:16PM -0600, > > Ralph Droms wrote > > a message of 56 lines which said: > > > >> I also think that if you query example.com (with no .* suffix) in > >> realm A, you may get a different answer than if you query > >> example.com in realm B. > > > > It is the exact same thing as the "search" directive in > > resolv.conf. When I type "ping www" at home or at work (or "ping > > www.lab" if you want an example with multiple labels), I ping a > > different machine. > > Hm. I guess the similarity extends to the observation that a user can reconfigure to avoid the serach directive issue, and can rec > onfigure to use an RDNSS in the desired "realm" (rather than, e.g., the RDNSS provided through DHCP) to avoid the side effects of d > raft-diao-aip-dns. > > - Ralph Pinging www.example.net doesn't touch the search list normally unless there is nothing at www.example.net. It really *is* a security issue to append search list elements to qualified names. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@resistor.net Wed Jun 20 00:42:57 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A5621F86F2 for ; Wed, 20 Jun 2012 00:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDOQdXMsCWww for ; Wed, 20 Jun 2012 00:42:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 191D321F8714 for ; Wed, 20 Jun 2012 00:42:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5K7gkdl007142; Wed, 20 Jun 2012 00:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340178174; i=@resistor.net; bh=ZAgUhzYmpJSc1+w4RTWANwz0VgSIPOLfqsxkvP74CiY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1QhPQo+M/NUlsPJhOnoiAQhaxx4cy8Z3PDlvGInLcwy+JgKM8bvfbBalARAalzZT3 vfC6echFBzUt1NFvUtCHzDu7b8h7HJjNK/mS8vAnHtm5MioEdvurNC2hgroXO8DiiE FhHwXQp4mrJs/Gxo4WgJNkaOQcsPQ6HNiT/Ih6Rs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340178174; i=@resistor.net; bh=ZAgUhzYmpJSc1+w4RTWANwz0VgSIPOLfqsxkvP74CiY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u36WEAXpBlc05Bok/S8u+pQZbgreSVKQm9hj8H9aFBcuTDVY7J0vzQJWRt0DssfFQ 5HEiA4eb6Gki6pcymCzEEn7Imlw1RLsygXBTAb8spUb6Q4kUSv6N8tpoj2VZiwpyUy sA8z9a8R5fq77Z90C/W8sho8uvR6Qpkw1KYA6KSQ= Message-Id: <6.2.5.6.2.20120619230716.09380bb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Jun 2012 00:41:36 -0700 To: dnsext@ietf.org, Yuping Diao , Ming Liao <644247110@qq.com>, Yongping Diao From: SM In-Reply-To: References:

Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 07:42:57 -0000 At 05:58 18-06-2012, Ondrej Sury wrote: >Exactly. And then it would be just a mess - every country would >create it's own Internet. It would be like letting a hundred flowers bloom for the governance people. >not that I promote the usage of existing tools for Internet censorship, >but at least those are just tools, and not the justification to split >the Internet. Nowadays it is simply referred to as legally restricted content. >Last, but not least, we (IETF) should produce technical documents >and not political. This is quite nice example of a document which The IETF produces political documents dressed up as technical proposals. They rarely take a line as in this draft as they are usually about technology. In the Introduction Section: "Internet Domain Name System (DNS) distributes domain name and IP address for the host on the Internet." What does the above mean? "In current Internet domain name hierarchy, the root DNS server authorizes and distributes all sub-layer DNS servers." That doesn't match the current definition. It has been said that "to remain a global network, the Internet requires the existence of a globally unique public name space". Do the authors of draft-diao-aip-dns-00 share the view that: (a) It is essential to have a common symbol set; and (b) common semantic interpretation of these symbols In Section 2.3: "In order to realize the transition from Internet to Autonomous Internet, each partition of current Internet should first realize possible self-government and gradually reduce its dependence on the foreign domain names, such as COM, NET et al." It is somewhat simplistic to look at domain names as a way to transition the Internet to some other form. Regards, -sm From nweaver@icsi.berkeley.edu Wed Jun 20 08:31:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F6421F8552 for ; Wed, 20 Jun 2012 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSJoCKbRZmER for ; Wed, 20 Jun 2012 08:31:47 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8D97521F8592 for ; Wed, 20 Jun 2012 08:31:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 568962C401D; Wed, 20 Jun 2012 08:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KjawrMmU+kpH; Wed, 20 Jun 2012 08:31:45 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0FB832C4006; Wed, 20 Jun 2012 08:31:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Wed, 20 Jun 2012 08:31:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu> References: To: draft-diao-aip-dns@tools.ietf.org X-Mailer: Apple Mail (2.1278) Cc: dnsext List Subject: Re: [dnsext] draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 15:31:48 -0000 My own $.02 as well, on just one little piece... > 5. Security Considerations >=20 > There is no additional security requirement than current domain = name > system. Security issues are not discussed in this memo. To put this succinctly, Hu?!? The point of this is to allow a country to "override the root": provide = its own DNS hierarchy which it controls to create an "Autonomous = Internet", namely, a namespace which deliberately excludes "undesirable" = names. Because unless you are excluding "undesirable" names, what is = the benefit of having two separate namespaces for the same name in = different countries? [1] This goes strictly contrary to DNSSEC, where, out of operational = concerns, all validators know the same universal root signing key. =20 Each "Autonomous Internet" would require its own root key, and any = client which may move between multiple AIPs would need to either = a-proiri know all distinct AIP root keys or somehow securely discover = the individual AIP's root key (HOW?!) There is also the namespace confusion problem, which is a security = problem: www.example.com in AIP A ?=3D www.example.com in AIP B. This is a huge concern, even if you solve the DNSSEC key problem, since = subverting either AIP will affect all clients in that AIP, and any = client who goes between AIPs. Fragmenting the namespace IS a security problem. [1] And if you want to block undesirable names, the existing = infrastructure does a good job of it. From dougb@dougbarton.us Wed Jun 20 13:16:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4831721F8649 for ; Wed, 20 Jun 2012 13:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iwNNVU5pQWr for ; Wed, 20 Jun 2012 13:16:15 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8297321F864B for ; Wed, 20 Jun 2012 13:16:15 -0700 (PDT) Received: (qmail 6656 invoked by uid 399); 20 Jun 2012 20:16:11 -0000 Received: from unknown (HELO ?172.17.194.139?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 20 Jun 2012 20:16:11 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4FE22F87.90004@dougbarton.us> Date: Wed, 20 Jun 2012 13:16:07 -0700 From: Doug Barton