From dnsext-bounces@ietf.org Tue Jun 5 19:22:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5411E80B6; Tue, 5 Jun 2012 19:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1338949327; bh=Zl7qU+5WCAEy0D7v8nDnSlilZdvPpIBP7fkHyUper20=; h=Date:From:To:Mime-Version:Message-ID:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=AkfXbRvhehKvs9ybqZ2mTKiK/IdvUa8qYckvCx3R+kplDA2ako79NClphrDp1QP6s XLioijBYVgMS9JgI61Z4o8Krkf4zT5wzKGmJH71cZ5BVXaUeuRP76RdU7gAdpIPSVz cD6EvNXFmvoxDbm54gR6MpD4VtzCXXPCppmj118A= 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 CFC9C11E80B6 for ; Tue, 5 Jun 2012 19:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.036 X-Spam-Level: * X-Spam-Status: No, score=1.036 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 itBIYlcmgafT for ; Tue, 5 Jun 2012 19:22:03 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D23B211E80AE for ; Tue, 5 Jun 2012 19:22:01 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhanghaikuo@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo-1c039910) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 06 Jun 2012 10:21:59 +0800 Date: Wed, 6 Jun 2012 10:22:00 +0800 From: zhanghaikuo To: dnsext X-Priority: 3 X-GUID: B7A0D04A-84D6-4E9C-8ADA-9AF1F1300CFE X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012060610215996870617@cnnic.cn> Subject: [dnsext] draft-haikuo-ckds-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhanghaikuo List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7012844566089713070==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org This is a multi-part message in MIME format. --===============7012844566089713070== Content-Type: multipart/alternative; boundary="----=_001_NextPart384467227441_=----" This is a multi-part message in MIME format. ------=_001_NextPart384467227441_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBkbnNleHQgd29ya2dyb3VwLA0KSSB3cm90ZSBhIGRyYWZ0IGZvciBETlNTRUMsIGFuZCBp dCBpcyBhIG5ldyBtZXRob2QgdG8gZGVhbCB3aXRoIHRoZSBlbWVyZ2VuY3kgcm9sbG92ZXIgZm9y IHRoZSBjb21wcm9taXNlZCBrZXkuDQp0aGUgZHJhZnQgaXMgZm9sbG93ZWQ6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYWlrdW8tY2tkcy8/aW5jbHVkZV90ZXh0PTEg DQoNCkkgaG9wZSBpdCBpcyB1c2VmdWwgZm9yIEROU1NFQy4NCg0KUmVnYXJkcw0KDQoNCg0KDQoN Cg0KSGFpa3VvIFpoYW5nDQpTb2Z0d2FyZSBEZXZlbG9wbWVudCBDZW50ZXIgIA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo9ID1Qcm9mZXNzaW9u IOKAoiBSZXNwb25zaWJpbGl0eSDigKIgU2VydmljZT0gPQ0KIA0KQ2hpbmEgSW50ZXJuZXQgTmV0 d29yayBJbmZvcm1hdGlvbiBDZW50ZXIg77yIQ05OSUPvvIkNClRlbDogKDg2MTApLTU4ODEzMTYz DQpIdHRwcy8vOiB3d3cuY25uaWMuY24gDQpBZGQ6IDQgU291dGggNHRoIFN0cmVldCwgWmhvbmdn dWFuY3VuLCBIYWlkaWFuIGRpc3RyaWN0LCAxMDAxOTAgQmVpamluZywgQ2hpbmENClBPQjogQmVp amluZyAzNDksIEJyYW5jaCA2 ------=_001_NextPart384467227441_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear dnsext workgroup,
I wrote a draft for DNSSEC, and it is a new method to deal with the=20 emergency rollover for the compromised key.
the draft is followed:
https://datatracker.ietf.org/doc/draft-haikuo-ckds/?include_text=3D1= =20
 
I hope it is useful for DNSSEC.
 
Regards
 
 
 
Haikuo Zhang

Software Development Center =20

---------------------------------------------------

=3D =3DP= rofession =E2=80=A2=20 Responsibility =E2=80=A2 Service=3D =3D

 

China=20 Internet Network Information Center =EF=BC=88CNNIC=EF=BC=89

Tel:=20 (8610)-58813163

Https//: = www.cnnic.cn=20

Add: 4 South 4th Street, Zhongguancun, Haidian di= strict,=20 100190 Beijing, China

= POB:= Beijing=20 349, Branch 6<= /P>

------=_001_NextPart384467227441_=------ --===============7012844566089713070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============7012844566089713070==-- From dnsext-bounces@ietf.org Sun Jun 10 17:23:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3AC21F8525; Sun, 10 Jun 2012 17:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339374237; bh=xZWdGQeEf4fRpR85uzUHE4frGrPOLZCYX4ms33wSSVU=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=CG/25L7PPy7jUeVBTzawCIdVJBCKRQSYlPZJvtxrfSAZPNsEWf5YAZkrj/9gTnK6H bXIYb44cWFkGIhWbgX7oRskZVxLf7AM48itDngX9Tka7ZMByHkTYxiUwA6g5/m3nQq uin3fqu0NdT3I58atKqNW7lkotiiHTZq5IEMXSPM= 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 02A1E21F8526; Sun, 10 Jun 2012 17:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MppFoCeDAdsW; Sun, 10 Jun 2012 17:23:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A166E21F84DE; Sun, 10 Jun 2012 17:23:56 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120611002356.22932.86191.idtracker@ietfa.amsl.com> Date: Sun, 10 Jun 2012 17:23:56 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-02.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : Domain Name System (DNS) IANA Considerations Author(s) : Donald E. Eastlake Filename : draft-ietf-dnsext-rfc6195bis-02.txt Pages : 20 Date : 2012-06-10 This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183 and 3597. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 11 10:43:47 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8E021F85C6; Mon, 11 Jun 2012 10:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339436627; bh=P8/82x0TTlKojRMmFaUhJiHJwLw7NXiaZ8mC14Jt2XY=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=psrq+2SWCkora2pMeuNOuuM2iB9KBEsq+OuS1w/UX+mAoW5Vg5IOZgdfyx9NSOkw1 0ez4otUoQ1Gi8kzs6nrdGWrJzWTsXxRiHDs/S8RIpABk2oRdQ8i/1YQD9AcylszB39 9kOTlxcbhpTZadm18N5Yt5hSgDG6CSlSz2ORRofc= 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 B9F2A21F8565 for ; Mon, 11 Jun 2012 10:43:46 -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 rjsW9qGu+xT3 for ; Mon, 11 Jun 2012 10:43:46 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1F621F85C6 for ; Mon, 11 Jun 2012 10:43:46 -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 q5BHhiUs026957 for ; Mon, 11 Jun 2012 13:43:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FD62E4E.4020007@ogud.com> Date: Mon, 11 Jun 2012 13:43:42 -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: "" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Dear colleagues This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ June 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 document we need a minimum of 5 reviewers. Olafur & Andrew _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 11 11:57:38 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6065621F84BF; Mon, 11 Jun 2012 11:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339441058; bh=Y3ZdFTO7r1KLAl4dVCH8c4QjA+RfNE8qC30dZwkfheY=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IrRchJmEObNaw2Fas4auPuPPKVgW+CQ+hPWpb3gWTm4tz35wmDnEm18TXlkOt9nJS VPdqrpK/gI4FpOufTMdiRr47LYV8TcwYX+Jq46mNmlUN9GKKObisZXJ6ZDdis13euS qxLQ9pAIeJ7i+d6ESJ8kAkacTTxu/WGqnlXS2r+s= 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 54A2821F8518; Mon, 11 Jun 2012 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 Rco7+8F3pCNn; Mon, 11 Jun 2012 11:57:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB14321F84B3; Mon, 11 Jun 2012 11:57:35 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120611185735.26525.99563.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 11:57:35 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-03.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-update-03.txt Pages : 6 Date : 2012-06-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 11 12:04:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA3721F85C6; Mon, 11 Jun 2012 12:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339441485; bh=bvXiiQSFEpzhE44PCsAAN9UbrQMtTTivq+hMk7bXJDE=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=vwgaZaF/SPm8yuk4svSTGzrGbz4Pq6Pzxa8ydeUmnnLFhho2Dv43RswbHeWxD63qq KIJoS4T4svwQbqNiR0FaYIT2JOY9oA8mPBA72lYIc10Aq71K8qxFRDh4QV5Zy6fHVh 23zNCSP/ZghlWvcRKf3zjF5MNL4o2zBohFDF/aV8= 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 2472D21F85E7 for ; Mon, 11 Jun 2012 12:04:43 -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 SmL2flXwP8bV for ; Mon, 11 Jun 2012 12:04:42 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07721F8518 for ; Mon, 11 Jun 2012 12:04:42 -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 q5BJ4fsl027598 for ; Mon, 11 Jun 2012 15:04:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FD64147.4040903@ogud.com> Date: Mon, 11 Jun 2012 15:04:39 -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: "" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dnsext] No Meeting at IETF-84 in Vancouver 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org As previously announced (in Paris) DNSEXT will not be meeting. Olafur & Andrew _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 11 12:10:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C6321F8543; Mon, 11 Jun 2012 12:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339441841; bh=fd3JHRIdSZlR89RYW2WwVwIu4t8mbnnF6336FmAVsdE=; h=From:MIME-Version:Date:In-Reply-To:To:References:Message-ID: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=phtnJy2qUzxPCc7UpO/r339VrQRnYdUOEqF6ouCshGh+SVf88zT96lhQzZnqo0Bc9 ftJe9RL9GmbRN8P1iJMs27bc+OwjMf1zKUh9f13h7U2qDPxohjat0PHRHUO4UY651V MljwK6ardOeOKFYNp6KhXuGNgIEcnPaIYfr/32ZI= 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 0187221F8543 for ; Mon, 11 Jun 2012 12:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 KPH-OAU70qYz for ; Mon, 11 Jun 2012 12:10:37 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B82D121F84E1 for ; Mon, 11 Jun 2012 12:10:36 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Jun 2012 15:10:21 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Jun 2012 15:08:18 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q5BJAYtO008291 for ; Mon, 11 Jun 2012 15:10:35 -0400 From: Scott Rose MIME-Version: 1.0 (Apple Message framework v1278) Date: Mon, 11 Jun 2012 15:10:34 -0400 In-Reply-To: <20120611185735.26525.99563.idtracker@ietfa.amsl.com> To: References: <20120611185735.26525.99563.idtracker@ietfa.amsl.com> Message-ID: X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-03.txt 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: , Content-Type: multipart/mixed; boundary="===============5549043230472206425==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============5549043230472206425== Content-Type: multipart/alternative; boundary="Apple-Mail=_EBCF1825-CF56-47E8-9105-A64BF2899F34" --Apple-Mail=_EBCF1825-CF56-47E8-9105-A64BF2899F34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" This revision removes some of the entires that didn't change, but were = overlooked in the -02 version and cleans up the references. =20 No significant wording changes from -02. =20 Scott =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 Scott Rose NIST 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 11, 2012, at 2:57 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA = Registry Updates > Author(s) : Scott Rose > Filename : = draft-ietf-dnsext-dnssec-registry-update-03.txt > Pages : 6 > Date : 2012-06-11 >=20 > 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. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-upda= te-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-updat= e-03.txt >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/= >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_EBCF1825-CF56-47E8-9105-A64BF2899F34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" This = revision removes some of the entires that didn't change, but were = overlooked in the -02 version and cleans up the references. =  

No significant wording changes from -02. =  

Scott

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 11, 2012, at 2:57 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 =           : DNS = Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
Author(s) =       : Scott Rose
Filename =        : = draft-ietf-dnsext-dnssec-registry-update-03.txt
Pages =           : 6
Date =            : = 2012-06-11

  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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-d= nssec-registry-update-03.txt

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

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registr= y-update-03.txt

The IETF datatracker page for this Internet-Draft = is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-= update/

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

= --Apple-Mail=_EBCF1825-CF56-47E8-9105-A64BF2899F34-- --===============5549043230472206425== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============5549043230472206425==-- From dnsext-bounces@ietf.org Tue Jun 12 12:10:11 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0E21F85C9; Tue, 12 Jun 2012 12:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339528211; bh=gI2hpFQ9QjxRcUwIdUxCpr+0AKV2oGfLC7mDrsQGoTo=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IoLvPpFf450qJvn40zrx1AmLyDLJOjUy/qG5UEJjzF2fXaWsbVK1Q52WWjGIPc+4E kyKojUYJ/cGG/WNLjrZSf3TwbVRpm3u0AJuuG3iTM/iOkHs9dE0xR8jhtmI91PmtPM +GPfq97cxoMv0eWzEOmh+e55bR9aty4be5xpbtlA= 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 1AAD621F86EA; Tue, 12 Jun 2012 12:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 PosNKFhOusyf; Tue, 12 Jun 2012 12:10:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7821F85A1; Tue, 12 Jun 2012 12:10:08 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612191008.895.6966.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 12:10:08 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-03.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-imp-status-03.txt Pages : 6 Date : 2012-06-12 Abstract: 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 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. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsext-dnssec-algo-imp-status-03 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 From dnsext-bounces@ietf.org Tue Jun 12 12:14:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7143921F8699; Tue, 12 Jun 2012 12:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339528489; bh=f2u5Shi1aC7buwvqFVFDh8balt46oS92ze977vSjDv8=; h=From:MIME-Version:Date:In-Reply-To:To:References:Message-ID: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=j+VU2oErsJyxM8IwXKD2kJE5mXMmaoeil7dRArMj4HdaI8qU5AoWdQe//MaGbhG3I bL3x28SPQqSGMrNqfH0oAHPneHNXJ2xsXG5AnpQRuzdUJXDW4BhqfaG2xQpzMR+7b9 cskq9dM1nGYFGnNbopSAMhAT7CttJY/MmFRgC1K0= 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 BE41621F8699 for ; Tue, 12 Jun 2012 12:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 KzlEw28nUTuy for ; Tue, 12 Jun 2012 12:14:45 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5321F867C for ; Tue, 12 Jun 2012 12:14:44 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 12 Jun 2012 15:14:39 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 12 Jun 2012 15:12:22 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q5CJEhXJ001739 for ; Tue, 12 Jun 2012 15:14:43 -0400 From: Scott Rose MIME-Version: 1.0 (Apple Message framework v1278) Date: Tue, 12 Jun 2012 15:14:43 -0400 In-Reply-To: <20120612191008.895.6966.idtracker@ietfa.amsl.com> To: References: <20120612191008.895.6966.idtracker@ietfa.amsl.com> Message-ID: <281F62E8-574F-4F10-ACB9-148A58BEAC6F@gmail.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-03.txt 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: , Content-Type: multipart/mixed; boundary="===============3767274428420331883==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============3767274428420331883== Content-Type: multipart/alternative; boundary="Apple-Mail=_8494EC22-3971-4895-AE76-F98C10C905D8" --Apple-Mail=_8494EC22-3971-4895-AE76-F98C10C905D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Not too many changes here. Mostly to make sure all the sections = (header, abstract, intro) are all in sync. =20 Scott =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 Scott Rose NIST 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 12, 2012, at 3:10 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Applicability Statement: DNS Security (DNSSEC) = DNSKEY Algorithm Implementation Status > Author(s) : Scott Rose > Filename : = draft-ietf-dnsext-dnssec-algo-imp-status-03.txt > Pages : 6 > Date : 2012-06-12 >=20 > Abstract: > 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 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. This document updates RFCs 2536, 2539, > 3110, 4034, 4398, 5155, 5702, and 5933. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/submission.filename }}-03 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-imp-sta= tus-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_8494EC22-3971-4895-AE76-F98C10C905D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Not = too many changes here.  Mostly to make sure all the sections = (header, abstract, intro) are all in sync. =  

Scott

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 12, 2012, at 3:10 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 =           : = Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm = Implementation Status
Author(s) =       : Scott Rose
Filename =        : = draft-ietf-dnsext-dnssec-algo-imp-status-03.txt
Pages =           : 6
Date =            : = 2012-06-12

Abstract:
  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 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. =  This document updates RFCs 2536, 2539,
  3110, 4034, = 4398, 5155, 5702, and 5933.


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

There's also a htmlized version available = at:
http://tools.ietf.org/html/submission.filename }}-03

A = diff from previous version is available = at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-= imp-status-03


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=_8494EC22-3971-4895-AE76-F98C10C905D8-- --===============3767274428420331883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============3767274428420331883==-- From dnsext-bounces@ietf.org Tue Jun 12 12:15:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C821F869F; Tue, 12 Jun 2012 12:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339528545; bh=bORj5Gc3hNH8ttPKL7JqQvP/nwlKTmqij8n+gcx1hSc=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=oXOt3PnwY/KZ0jI3HqLryYH70JrXUHRL3WGB8TFca1oY1oCg7zWczNHQfT/Li3UD2 9dneghEbRBEAMPiM1JbnxcEoKkGQn/FKtlNjOHIDxQXCoHnrLrF9rKQz1erzL8LHCN dzlE4P+pA0xBqTbpJ8vdZF4sjIO8+foqpyYge100= 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 1C10121F869F for ; Tue, 12 Jun 2012 12:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, HTML_MESSAGE=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 PakBJwd9Plak for ; Tue, 12 Jun 2012 12:15:43 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id CD31721F8694 for ; Tue, 12 Jun 2012 12:15:42 -0700 (PDT) Received: from [70.88.139.89] (account steve@shinkuro.com HELO [192.168.168.111]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20608469; Tue, 12 Jun 2012 19:17:57 +0000 Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Crocker In-Reply-To: <281F62E8-574F-4F10-ACB9-148A58BEAC6F@gmail.com> Date: Tue, 12 Jun 2012 15:15:34 -0400 Message-Id: <4C4A3382-1499-4D7F-AB2F-55E5DB867DC0@shinkuro.com> References: <20120612191008.895.6966.idtracker@ietfa.amsl.com> <281F62E8-574F-4F10-ACB9-148A58BEAC6F@gmail.com> To: Scott Rose X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-03.txt 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: , Content-Type: multipart/mixed; boundary="===============0667345523870773857==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============0667345523870773857== Content-Type: multipart/alternative; boundary=Apple-Mail-58-444081553 --Apple-Mail-58-444081553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tedious but necessary. Much appreciated. Steve On Jun 12, 2012, at 3:14 PM, Scott Rose wrote: > Not too many changes here. Mostly to make sure all the sections = (header, abstract, intro) are all in sync. =20 >=20 > Scott >=20 > =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 > Scott Rose > NIST > 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 >=20 > On Jun 12, 2012, at 3:10 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> 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. >>=20 >> Title : Applicability Statement: DNS Security (DNSSEC) = DNSKEY Algorithm Implementation Status >> Author(s) : Scott Rose >> Filename : = draft-ietf-dnsext-dnssec-algo-imp-status-03.txt >> Pages : 6 >> Date : 2012-06-12 >>=20 >> Abstract: >> 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 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. This document updates RFCs 2536, 2539, >> 3110, 4034, 4398, 5155, 5702, and 5933. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/submission.filename }}-03 >>=20 >> A diff from previous version is available at: >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-imp-sta= tus-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail-58-444081553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Not too many changes here. =  Mostly to make sure all the sections (header, abstract, intro) are = all in sync.  

Scott

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 12, 2012, at 3:10 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 =           : = Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm = Implementation Status
Author(s) =       : Scott Rose
Filename =        : = draft-ietf-dnsext-dnssec-algo-imp-status-03.txt
Pages =           : 6
Date =            : = 2012-06-12

Abstract:
  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 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. =  This document updates RFCs 2536, 2539,
  3110, 4034, = 4398, 5155, 5702, and 5933.


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

There's also a htmlized version available at:
http://tools.ietf.= org/html/submission.filename }}-03

A diff from previous = version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dns= sec-algo-imp-status-03


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

_______________________________________________
dnsex= t mailing = list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

________________________________= _______________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org= /mailman/listinfo/dnsext

= --Apple-Mail-58-444081553-- --===============0667345523870773857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============0667345523870773857==-- From dnsext-bounces@ietf.org Wed Jun 13 11:47:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129011E80B7; Wed, 13 Jun 2012 11:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339613232; bh=bGQS8ppKuWf3FHBQ2quSddzscKvZuotPDTVL8omA3R8=; h=Message-Id:From:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ldYid71EaB8y2ihtS3XamEpKJ4Ui5Ag2WuEGFGEjRKJ8vmljqo6jYSG5XnfzUM8JP Vu6yfQwWlgAgPef/kKImyJQpLM+vRbKLx00HDjgS2gpI7GM5hR+eqL0QUwsIWq665b ry6T6jnIrTRA6rMtTfiBCKHhYP6/YNVmeefOSALY= 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 1E9DA11E80B7 for ; Wed, 13 Jun 2012 11:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 UjNex4PKPtJe for ; Wed, 13 Jun 2012 11:47:08 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 23B7C11E80B2 for ; Wed, 13 Jun 2012 11:47:08 -0700 (PDT) Received: (qmail 15318 invoked from network); 13 Jun 2012 18:46:59 -0000 Received: from unknown (HELO gem-wbe38.prod.mesa1.secureserver.net) (64.202.189.52) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 13 Jun 2012 18:46:58 -0000 Received: (qmail 31407 invoked by uid 99); 13 Jun 2012 16:00:17 -0000 X-Originating-IP: 172.19.38.144 User-Agent: Workspace Webmail 5.6.18 Message-Id: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> From: "Michael Sheldon" To: "Olafur Gudmundsson" , "dnsext@ietf.org" Date: Wed, 13 Jun 2012 09:00:16 -0700 Mime-Version: 1.0 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In section 3.1: "There are currently five QTYPEs assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR." I would consider changing "* (ALL)" to "* (ALL/ANY)" While officially type 255 is * ALL, just about every implementation I've ever seen refers to it as ANY. Michael Sheldon Dev-DNS Services GoDaddy.com > -------- Original Message -------- > Subject: [dnsext] WGLC: RFC6195bis IANA guidance > From: Olafur Gudmundsson > Date: Mon, June 11, 2012 10:43 am > To: "" > > > Dear colleagues > > This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ > June 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 > document we need a minimum of 5 reviewers. > > Olafur & Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 14 04:30:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1896A21F8528; Thu, 14 Jun 2012 04:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339673442; bh=NGVPZuKCMx1usYWs4H0Dk/I9kPIXQBLViWLeRWvydk0=; h=From:To:Date:Message-ID:Content-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=wLIx/SQpAemFww0hkulogrU0/wxZZ/66tSDu5dZallZ9XYF45tHgYRrg8iiwPc4Du vj+x9hBXVnD0aWYOTZBFt9j3gFVe2hMbs7E493uykQ+ilfskgPccdi4TgaDylOFbbl iuZ+IcrSV82Rd35mMXVjrofpDRpHErHvAzWbzoLM= 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 51C3221F8528 for ; Thu, 14 Jun 2012 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3I+6RpqMf-hS for ; Thu, 14 Jun 2012 04:30:39 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 08F5521F8518 for ; Thu, 14 Jun 2012 04:30:37 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=sWuI+p+GWJpCwvuLwyCoRGD59m655opOAsyt3Fl63Fm8QXyD4s6y8s4N X0idEODQys2IULazX23nMunrDzzacf2rz2I2Ds/OfrTmEe9CRoLEdeIhe OquPs1vltqHypOb; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1339673439; x=1371209439; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20D NS=20RRTYPEs=20for=20ILNP=20review=20-=20Comments=20perio d=20end=20July=205th|Date:=20Wed,=2013=20Jun=202012=2022: 00:50=20+0000|Message-ID:=20|To:=20"dnsext@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<51a71aad-41f0-4985-aa31-129a5dd83315>; bh=hqeabu8M3wglMsDAmt4W0XrdpS5oObe7DTEL4g01Z9A=; b=zBcPn5jH4eoD+X1VXb2UIOL6Ngnu2W9OZlqUBVCSzHZMjjdRdy0XsAsf onufrvdwpWNlbWKikFR1dv63Ui16VK9X6Uv2+iEoO8FS+XO7GishPVRDe l1Tpy8vyXN7O9gv; X-IronPort-AV: E=Sophos;i="4.77,406,1336345200"; d="scan'208";a="40879721" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 13 Jun 2012 23:00:49 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Wed, 13 Jun 2012 23:00:48 +0100 From: Roy Arends To: "dnsext@ietf.org" Thread-Topic: DNS RRTYPEs for ILNP review - Comments period end July 5th Thread-Index: AQHNSa/9+x84EXpypEO1mag2mEigIw== Date: Wed, 13 Jun 2012 22:00:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <51a71aad-41f0-4985-aa31-129a5dd83315> MIME-Version: 1.0 Subject: [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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Dear Colleagues, Below is a completed template requesting new RRTYPE assignments under the procedures of RFC6195. This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocations for ILNP specified in http://www.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt If you have comments regarding this request please post them here before July 5th 18:00 UTC. Best Regards, Roy Arends DNS RRTYPE PARAMETER ALLOCATION TEMPLATE When ready for formal consideration, this template is to be submitted to IANA for processing by emailing the template to dns-rrtype-applications@ietf.org. A. Submission Date: To be determined. B. Submission Type: [X] New RRTYPE C. Contact Information for submitter: Name: R. Atkinson Email Address: rja.lists@gmail.com International telephone number: unlisted Other contact handles: D. Motivation for the new RRTYPE application? Support for an experimental set of IP extensions that replace the concept of an "IP Address" with distinct "Locator" and "Identifier" values. E. Description of the proposed RR type. Please see: http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt for a full description. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? There is no RRTYPE that fulfils the need due to the new semantics of Locator and Identifier values. The AAAA record combines both Locator and Identifier, so has significantly different semantics than having separate L64 and NID record values. The AAAA record also lacks scalability and flexibility in the context of the experimental protocol extensions that will use the NID and L64 records, as any valid NID record value for a node can be used on the wire with any valid L64 record value for the same node. 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. Lastly, the AAAA and CNAME RR Types lack a Preference field to rank responses. Such Preference information is required for ILNP in order to support the use of multiple instances of NID, L32, L64 and LP records. G. What mnemonic is requested for the new RRTYPE (optional)? As described in this draft, "NID", "L32", "L64", and "LP". H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? Existing registry of DNS Resource Record (RR) data TYPE values should be used. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597]) ? No. J. Comments: This document defines "ILNP-aware" DNS servers or DNS resolver as a DNS server (authoritative or recursive) that MAY include other ILNP RRTypes in the Additional section of a DNS response that match a QNAME (if size permits). This is to reduce the number of DNS stub resolver follow-up DNS queries. and only applies when the QTYPE is either NID, L32, L64, or LP. There is no signalling mechanism for this Additional section processing, and this is believed to be compatible with existing non-ILNP-aware DNS servers and DNS stub resolvers. No changes are required for existing deployed DNS servers or DNS resolvers. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 14 06:06:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398CD21F869C; Thu, 14 Jun 2012 06:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339679190; bh=Y5e4NhJxaiAIbhZAiA1pYiBUwEZsOnoFSb3Tr224J5Y=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ri7mKrrAxAnL6sDw+Z/E5AkcTih+lMJ7Ohv1Lt1V8GjDHqIEeRmT/nZZg3mplMXSM rbNdb1nN7ZX/7TTLQXgOQUKQIKjNBnrc+KC89LXT94yGKZKlAMLffvTPhM7fO4O3V4 VEGpZ75eYJ/AfyPDqY/Kh+f9/tJgE5OEs3NpYSpI= 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 F04FD21F869C for ; Thu, 14 Jun 2012 06:06:28 -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_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 d5Qj9FHxxzwJ for ; Thu, 14 Jun 2012 06:06:28 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0946121F8692 for ; Thu, 14 Jun 2012 06:06:26 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA299569084; Thu, 14 Jun 2012 15:04:44 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA00956; Thu, 14 Jun 2012 15:04:43 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201206141304.PAA00956@TR-Sys.de> To: dnsext@ietf.org Date: Thu, 14 Jun 2012 15:04:42 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: ogud@ogud.com 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I have once more read the most recent version of the rfc6195bis draft and can approve that most of my previous review comments for RFC 6195 and this draft have been acted upon satisfactorily. My special thanks to Donald for his patience with my persistent urges to improve the clarity in the visual presentation of the tables; I think the pleasant result is worth the efforts. Michael Sheldon's remark about "ALL" vs. "ANY" has lead me to once more check the updated registry tables, and I got stuck at two details, which lead to new considerations: (1) Section 3.1.4 and/or Appendix B Maybe the IESG will call for a citation for closing the AFSDB sub-registry. RFC 5864 is the proper reference (and its author has approved the formal closing after checking with the AFS community). (2) Section 3.2 In the RCODE registry (Section 2.3), there is an apparent overloading of RCODE=16: BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845). Looking back into RFC 2845, it seems that the clerical error has happened at IANA when acting upon the assignments in that RFC. The second paragraph of Section 7 of RFC 2845 (on top of page 13) clearly states: ! IANA is expected to create and maintain a registry of "TSIG Error ! values" to be used for "Error" values as defined in section 2.3. ! Initial values should be those defined in section 1.7. New TSIG ! error codes for the TSIG error field are assigned using the IETF ! Consensus policy defined in RFC 2434. Note that the TSIG Error field is a component of TSIG RDATA distinct from the RCODE field in the DNS message header and its extension in OPT RRs. An According to RFC 2845 (which seems to be mostly unaware of EDNS, besides references to binary labels), there is an intentional semantical overlap for Error values 0..15, which are specified as being identical with the non-extended RCODES (0..15) in sect. 1.7 of RFC 2845; the "new" TSIG Error values 16..18 are to be signaled together with RCODE = NotAuth(9) (originally specified in RFC 2136). The idea there obviously was to make TSIG independent of the OPT RR, i.e. to allow TSIG without EDNS, but to this end RFC 2845 likely better had accomodated the extended RCODE BADVERS(16) assigned by RFC 2671 and chosen Error values 17..19 for TSIG purposes. However, IANA obviously has registered the actual new values 16..18 in the RCODE registry and _not_ established a TSIG Error code registry. Mistakes happen, and it also may be wise to have RCODE values 17 and 18 "reserved" so that additional overloading cannot arise in the future. But IMO it would be worth adding "[*]" to the three RCODE registry entries based on RFC 2845: BADSIG, BADKEY, and BADTIME, e.g.: 16 BADSIG TSIG Signature Failure [*] [RFC2845] 17 BADKEY Key not recognized [*] [RFC2845] 18 BADTIME Signature out of time window [*] [RFC2845] ... and to add a footnote to the rigistry that says (e.g.): [*] These values are only to be used in the Error field of TSIG RRs; they cannot appear in the (extended) RCODE field of OPT RRs. Also, for added precision and consistency with RFC 2845 and RFC 2930, the last clause in the first paragraph of Section 2.3 should perhaps be adjusted as follows: OLD: and the TSIG and TKEY RRs have a 16-bit RCODE field. ^^^^^ NEW: and the TSIG and TKEY RRs have a 16-bit Error field. ^^^^^ Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 14 10:25:37 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9BC21F8732; Thu, 14 Jun 2012 10:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339694736; bh=3VzVDrnhkJGsbktw8bOW+hRmVxbuandJnFcBXLdxBLg=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=uUH7OfA94kRPjDLqVEcp9N9WQQZYFt4PnNM/p5TfGFoJaGUzDl96aJW2Jnj+eAMS5 sxcySTEFFSwS7Ojcuc6RUwRzQnaIgPmZYIRcBldhmuyMY8OaT6eV1oVbG2PlYsQtC7 RNX/ykppgs1JsFDyRKtIrGEXVkIOEpeWfBofML2I= 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 2601F21F8710; Thu, 14 Jun 2012 10:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 pVLAK2zbTtif; Thu, 14 Jun 2012 10:25:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82D21F86D4; Thu, 14 Jun 2012 10:25:33 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614172533.31670.90292.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 10:25:33 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-07.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 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 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-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 From dnsext-bounces@ietf.org Thu Jun 14 10:42:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8A21F8716; Thu, 14 Jun 2012 10:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339695728; bh=yEP4nXGorGS2SjmBIZoGbWyFY/eoIfYFk/3FWN3pr68=; h=From:MIME-Version:Date:In-Reply-To:To:References:Message-ID: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=hii3YkoovjTy13gWfmN8SZhElkvQixXIPlbjkePxzE1BALNUE40Yx15PuuEBpd+nB Z1irdEWHXKpZJyeKwugqjAwn4Aw29EJWY80zuIYgIhEtBZgutatGjz4NfwapMkbs0C JsjIwnbHZMSf1HyE69OWxiM6SjbkvHNhB7ADhNrA= 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 132D821F86F9 for ; Thu, 14 Jun 2012 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 0ZRK0NPenkh5 for ; Thu, 14 Jun 2012 10:42:05 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9A21F85DA for ; Thu, 14 Jun 2012 10:42:04 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 14 Jun 2012 13:41:56 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Thu, 14 Jun 2012 13:39:34 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q5EHg1M3001529 for ; Thu, 14 Jun 2012 13:42:01 -0400 From: Scott Rose MIME-Version: 1.0 (Apple Message framework v1278) Date: Thu, 14 Jun 2012 13:42:01 -0400 In-Reply-To: <20120614172533.31670.90292.idtracker@ietfa.amsl.com> To: References: <20120614172533.31670.90292.idtracker@ietfa.amsl.com> Message-ID: <51755F64-A219-4141-B964-DBA47763DC34@gmail.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-07.txt 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: , Content-Type: multipart/mixed; boundary="===============5034088593962274294==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============5034088593962274294== Content-Type: multipart/alternative; boundary="Apple-Mail=_271E5361-3271-4B6F-B5B4-C6B92FA5FA6B" --Apple-Mail=_271E5361-3271-4B6F-B5B4-C6B92FA5FA6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" This revision incorporates comments from the -06 version and changes to = some of the RFC 2119 language. Comments on the 2119 keyword usage welcome, as they do change the tone = of the text. Scott =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 Scott Rose NIST 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: >=20 > 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. >=20 > Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-07.txt > Pages : 8 > Date : 2012-06-14 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-07 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-= 07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_271E5361-3271-4B6F-B5B4-C6B92FA5FA6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" This = revision incorporates comments from the -06 version and changes to some = of the RFC 2119 language.

Comments on the 2119 = keyword usage welcome, as they do change the tone of the = text.

Scott

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-- --===============5034088593962274294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============5034088593962274294==-- From dnsext-bounces@ietf.org Thu Jun 14 11:09:21 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C1421F8734; Thu, 14 Jun 2012 11:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339697357; bh=w0Kh6Aj1BtvK8Uhg9bTkLLuksaA/FEi7GyXIQAPZ31w=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=xU13zlB80siItD6ctXT0CprnXCiUL14IbksbydYGkU1nsU4qrvKIjOEzDAR9jdxWU M6qOHw8rxG9Ejkx2OFek60ZugPmRK9HEIckBsVSenpGfnNQOjuL8DktdSF/Fran+OV Cmpp15ETcw0m6SN3oEte7zJv3TD+k/EWNCVhewzc= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org > 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Jun 17 10:01:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7526C21F85FB; Sun, 17 Jun 2012 10:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339952470; bh=2UxCSeOSdUVjt4kmEbJqqAU+DxHQwLXyGLXJhyY+r/w=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Q5Qne+KD5IXHpeUfU6+L9f+mZBWEVjItEhRiJLV/mTGks348gaLuKIjsgBZTxpThC A4e3kQziQKPWChf+2wr9E5bCipecqE0NL/uvJiRQRpFjFTDaS3KH0rtoKcXuJEoMAS d7yrQkDTS0VXL7RQysEZ1c1UOoaqw9Zd6HCqC09o= 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 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Jun 17 23:27:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F611E80D7; Sun, 17 Jun 2012 23:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340000830; bh=utnHKZbQdObUvg9QrRYSezXE/TLdDl7VeeCi4p/hJIY=; h=To:From:Message-Id:Date:Cc:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=mXg/lOEKTXV5M0h7AT703eC4zFKtRqxs0gjpE7u0ZeGauFlBv/l/eIEUlMvrAVP2U w31eSUPsxtLxb6snH+0qTQMUQonW4bZI2y04k0wqoDHdshC4hdtXa69zupdSjtXGlR nnGb8YGyfdwr7VWHtnce2azA48BItcXhUi0g59oI= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 05:58:46 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD621F862F; Mon, 18 Jun 2012 05:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340024326; bh=bKcX+bF0heTmL9HIA/s9FUaNUIzGiq2V1MWmh3SyN68=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RYdLDHumbzaa8pBnMAfisP9hNSOGdOni7Ryr7mVSD4/2vE/NBXH8o/a4eMeodvdnW ik2ay98gip6prAzdZwGPkhYDHU1Nx6/AwsvGyZUxHBUy1TSLX9MkMrS+WXcWhJk1m2 85Bw/PCxWlRXAEMV7T08/IfUTzi3S/et906GRccY= 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) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Mon, 18 Jun 2012 14:58:31 +0200 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org SGksCgp0aGFua3MgVG9ueSBmb3IgcG9pbnRpbmcgdGhhdCBvdXQuLi4KCk9uIDE3LiA2LiAyMDEy LCBhdCAxOTowMSwgVG9ueSBGaW5jaCB3cm90ZToKCj4gU28gdGhpcyAiRE5TIEV4dGVuc2lvbiBm b3IgQXV0b25vbW91cyBJbnRlcm5ldCIgY2F1Z2h0IG15IGV5ZS4gVGhlcmUgYXJlCj4gY2xlYXJs eSBhIG51bWJlciBvZiBhdXRvbm9teS1yZWxhdGVkIHJlcXVpcmVtZW50cyB0aGF0IHRoZSBETlMg ZG9lcyBub3QKPiBzYXRpc2Z5LCBzdWNoIGFzIHByaXZhdGUvaW50ZXJuYWwgbmFtZXMgYW5kIGFk LWhvYyBuZXR3b3JraW5nLiBUaGVzZSBhcmUKPiBjdXJyZW50bHkgc2F0aXNmaWVkIGJ5IHdvcmtp bmcgb3V0c2lkZSB0aGUgYXJjaGl0ZWN0dXJlIC0gQklORCdzIHZpZXdzIGFuZAo+IG11bHRpY2Fz dCBETlMgcmVzcGVjdGl2ZWx5Lgo+IAo+IEhvd2V2ZXIgdGhpcyBkcmFmdCBpcyBub3QgYWJvdXQg YW55IG9mIHRoYXQuIEl0IGFwcGVhcnMgdG8gYmUgcHJvcG9zaW5nIGEKPiB0ZWNobmljYWwgd29y a2Fyb3VuZCBmb3IgZGlzc2F0aXNmYWN0aW9uIHdpdGggSUNBTk4ncyBtYW5hZ2VtZW50IG9mIHRo ZQo+IEROUyBuYW1lc3BhY2UuCgpJIGFtIG5vdCBzbyBzdXJlIGFib3V0IHRoZSBtb3RpdmF0aW9u cywgYnV0IEkgc2VlIHRoaXMgZHJhZnQgYXMgZGFuZ2Vyb3VzCnByZWNlZGVudC4gIFVuaWZpZWQg RE5TIHRyZWUgd2FzIGFuZCBpcyBhbiBpbXBvcnRhbnQgYnVpbGRpbmcgYmxvY2sgb2YgdGhlCklu dGVybmV0IGFuZCBzdGFuZGFyZGl6aW5nIEROUy1zcGxpdCB3b3VsZCBtZWFuIHRoZSBlbmQgb2Yg dGhlIEludGVybmV0CmFzIHdlIGtub3cgaXQuCgo+IEJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IG5v bmUgb2YgdGhpcyBpcyBuZWNlc3Nhcnk6IGFsbCBpdCBpcyBkb2luZyBpcyBzaGlmdGluZyB0aGUg bmFtZXNwYWNlIGRvd24gYSBsZXZlbC4KCgpFeGFjdGx5LiAgQW5kIHRoZW4gaXQgd291bGQgYmUg anVzdCBhIG1lc3MgLSBldmVyeSBjb3VudHJ5IHdvdWxkIGNyZWF0ZSBpdCdzIG93biBJbnRlcm5l dC4KCj4gVGhhdCBpcyB5b3UgY2FuIGdldCBhIHNpbWlsYXIgcmVzdWx0IFsuLi5dIHVzaW5nIGV4 aXN0aW5nIHRlY2hub2xvZ2llcy4KCgorMQoKbm90IHRoYXQgSSBwcm9tb3RlIHRoZSB1c2FnZSBv ZiBleGlzdGluZyB0b29scyBmb3IgSW50ZXJuZXQgY2Vuc29yc2hpcCwKYnV0IGF0IGxlYXN0IHRo b3NlIGFyZSBqdXN0IHRvb2xzLCBhbmQgbm90IHRoZSBqdXN0aWZpY2F0aW9uIHRvIHNwbGl0CnRo ZSBJbnRlcm5ldC4KCkxhc3QsIGJ1dCBub3QgbGVhc3QsIHdlIChJRVRGKSBzaG91bGQgcHJvZHVj ZSB0ZWNobmljYWwgZG9jdW1lbnRzCmFuZCBub3QgcG9saXRpY2FsLiAgVGhpcyBpcyBxdWl0ZSBu aWNlIGV4YW1wbGUgb2YgYSBkb2N1bWVudCB3aGljaAooaW4gbXkgdmlldykgcHV0cyBwcmlvcml0 aWVzIG9mIG5hdGlvbmFsIHN0YXRlcyBvdmVyIHRoZSBvcGVubmVzcwphbmQgb3ZlcmFsbCBjb21w YXRpYmlsaXR5IG9mIHRoZSBJbnRlcm5ldC4KCk8uCi0tCiBPbmTFmWVqIFN1csO9IC0tIENoaWVm IFNjaWVuY2UgT2ZmaWNlcgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQogQ1ouTklDLCB6LnMucC5vLiAgICAtLSAgICBMYWJvcmF0b8WZZSBDWi5OSUMKIEFtZXJp Y2thIDIzLCAxMjAgMDAgUHJhaGEgMiwgQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWouc3Vy eUBuaWMuY3ogICAgaHR0cDovL25pYy5jei8KIHRlbDorNDIwLjIyMjc0NTExMCAgICAgICBmYXg6 KzQyMC4yMjI3NDUxMTIKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4 dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Mon Jun 18 06:13:37 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3212421F8565; Mon, 18 Jun 2012 06:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340025217; bh=i1iS3L5BrhTT4i15ktobviEBf+58mJsOFyTVXZR+zs0=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QdOsYqkrAWgh9x7UZIe/SigCFwlHAeTyrQgqQvojDwIZ0Cyi+FtMt0+2+AA76vkCj UQQhialXX52btaF+fFFtYH0GXh3EZDp+IZnCM5ikGHKrKEldsvBQdk2ZqHPdox8Lxp nPow8JDRNoAyvZngDNRYC3CF7D0gFQoT+gJoU6Ac= 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-Disposition: inline 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. 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... _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 06:27:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965C621F85D0; Mon, 18 Jun 2012 06:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340026021; bh=AIyqlT9kFN4er4zMLfMaihwiz19OhmatV1L1u+TCNBk=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=ljMS2Qg5chfTpdPKIFrq99bOfxG8WO98BWy6McNQ30RK5sI7EVs0l7HCuX16S8mue pKwNbzyovdixHfzBdW67ElZEds9Ag7rq0nY3CCbv9RWfgXtQbOJGS3PQ/+7+IyMAzL zsyUWCzS6++3uJ9TSX2Nrd1D4SisS9rTomeQtzNE= 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: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 06:29:18 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7A921F85E1; Mon, 18 Jun 2012 06:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340026158; bh=atAKI7mPKk++H0Tdh4BSL5vGmhEwzdCgkNASW6+x5Z0=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=t6VxAfij6myKGQun4dYi/PAvMpoyLxsrMrCHZQzKz3ts53hgSLpfZpoyz9UUHTc4g xA7dgKOpkbv3rOg805zrNYxLq5+GSBBg7wKIFbcbbRMx1j4p/IGC9qzmp1mkDeUGdg +lkx5greuu0xhIr382D2YeDtaJdjpqUZ6+RZV8QM= 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) 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 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Ck9uIDE4LiA2LiAyMDEyLCBhdCAxNToxMiwgU3RlcGhhbmUgQm9ydHptZXllciB3cm90ZToKCj4g T24gTW9uLCBKdW4gMTgsIDIwMTIgYXQgMDI6NTg6MzFQTSArMDIwMCwKPiBPbmQ/ZWogU3Vyw70g PG9uZHJlai5zdXJ5QG5pYy5jej4gd3JvdGUgCj4gYSBtZXNzYWdlIG9mIDM1IGxpbmVzIHdoaWNo IHNhaWQ6Cj4gCj4+IFVuaWZpZWQgRE5TIHRyZWUgd2FzIGFuZCBpcyBhbiBpbXBvcnRhbnQgYnVp bGRpbmcgYmxvY2sgb2YgdGhlCj4+IEludGVybmV0IGFuZCBzdGFuZGFyZGl6aW5nIEROUy1zcGxp dCB3b3VsZCBtZWFuIHRoZSBlbmQgb2YgdGhlCj4+IEludGVybmV0IGFzIHdlIGtub3cgaXQuCj4g Cj4gVGhlIEktRCBkb2VzIG5vdCBzcGxpdCB0aGUgRE5TIGF0IGFsbC4gSXQgcGxheXMgd2l0aCB3 b3JkcyBieQo+IHByZXRlbmRpbmcgaXQgd2lsbCBhbGxvdyBzZXZlcmFsIHJvb3RzIGJ1dCB0aGlz IGlzIG5vdCB0cnVlLiBJbnN0ZWFkLAo+IGl0IGNyZWF0ZXMgYSBzdXBlci1yb290ICh0aGUgb25l IHdoaWNoIHdpbGwgYWxsb2NhdGUgdGhlIEFJUHMsIHRoZSAuQQo+IGFuZCAuQiBpbiB0aGUgZXhh bXBsZXMpIGFuZCB0aGVyZWZvcmUganVzdCBkaXNwbGFjZXMgdGhlIChyZWFsKQo+IHByb2JsZW1z IHRvIHRoZSBzdXBlci1yb290LgoKV2VsbCwgeWVzIGFuZCBuby4gIEl0J3Mgc29tZXRoaW5nIGlu IGJldHdlZW4uCgpJZiB5b3UgYXJlIGluICcuQScgQUlQLCB5b3Ugd2lsbCBub3QgaGF2ZSB0byB0 eXBlIC5BIGF0IHRoZSBlbmQgb2YgeW91cgpxdWVyeSwgc28gZ292LmNuIHdpbGwgd29yayBhcyBp cyB3aXRob3V0ICcuQScuICBPbmx5IGlmIHlvdSB3YW50IHRvIGdvCnRvICd1bmFwcHJvdmVkJyBz aXRlIGluIC5CIHRyZWUgeW91IHdpbGwgaGF2ZSB0byB0eXBlCidlbmNyeXB0ZWQuZ29vZ2xlLmNv bS55b3Utd2lsbC1iZS1hcnJlc3RlZCcgaW50byB5b3VyIGJyb3dzZXIgVVJMIGJhci4KCj4gVGhp cyBpcyB3aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9mICJzZXZlcmFsIHJvb3RzIiBzeXN0ZW1zIGRv OiBjcmVhdGUgYQo+IG5ldyByb290IGJ1dCBkbyBub3QgY2FsbCBpdCBhIHJvb3QuIE5ld3NwZWFr IGF0IGl0cyBiZXN0Li4uCgoKWXVwLCBJIGFncmVlLgoKTy4KLS0KIE9uZMWZZWogU3Vyw70gLS0g Q2hpZWYgU2NpZW5jZSBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCiBDWi5OSUMsIHoucy5wLm8uICAgIC0tICAgIExhYm9yYXRvxZllIENaLk5JQwog QW1lcmlja2EgMjMsIDEyMCAwMCBQcmFoYSAyLCBDemVjaCBSZXB1YmxpYwogbWFpbHRvOm9uZHJl ai5zdXJ5QG5pYy5jeiAgICBodHRwOi8vbmljLmN6LwogdGVsOis0MjAuMjIyNzQ1MTEwICAgICAg IGZheDorNDIwLjIyMjc0NTExMgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K ZG5zZXh0IG1haWxpbmcgbGlzdApkbnNleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbnNleHQK From dnsext-bounces@ietf.org Mon Jun 18 10:27:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AD621F86C4; Mon, 18 Jun 2012 10:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340040459; bh=KtL7RA5fsA9ySx1tmWXpNR12vcSnrbGdX0ycLHUnZuY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=SV/qhihz8Wi3XnBXLmj2ndPLdPR5/0gGz1hAMr8LzI4KT7wKUOooAeZwUgOEQ4es6 cgbyv0EWIPRY2Ndul9AnmrTp5lAGEx+h6YE+7uiYYtNimYOmcSvAGAkMz81WNqu1Kc eQPI3bfgE0FAaWtqZlPLjwSmwjtav6CVUX0D/nRk= 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> 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 11:02:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4EB21F86EB; Mon, 18 Jun 2012 11:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340042533; bh=KisXKw8iYDCVpNGvxE6peNAedN6cioaeYQlmFM3efaQ=; h=Date:From:To:Message-ID:MIME-Version:Content-Type:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Sender; b=wy3fGndAS8bqvxqJRIkOA0AaG6WHTG1TGwOSda04LhAq58E3Vcsquv8YUWekOcyPz yHaUkbV1JN01h1rSHX4TYc/n8lEtYqHWV+g6LEsuYB/7Jxytxdnq6hNK5SKMBOib/y pgbq/vywnSTRJjnnq+IXWq4IrNK+rqcFzpXrMp7s= 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: , Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --+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 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --+QahgC5+KEYLbs62-- From dnsext-bounces@ietf.org Mon Jun 18 11:04:41 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4CC21F86EA; Mon, 18 Jun 2012 11:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340042681; bh=hQgdlT1JNTbh7sIAxpYQq97IxW+EN4OtBPbwBIXD1Yw=; h=Date:From:To:Message-ID:MIME-Version:Content-Type:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Sender; b=yFm1RJ1S8xiBGhUe8UUix/fqZ/AzBqQ1eMU/hAAfMsW0LaAa7rbWll/jgsqRQULiu c3GJZ9jnPMhbVu+dC6eeNVJnSnc6U4tGBgkEWdThyhZpqpY9aEAGg/YjruhV4R9eWI BPC5QwAuXgg0jsIBzGWl4jElVi4crIwP1ya1foZw= 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: , Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --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 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --TRYliJ5NKNqkz5bu-- From dnsext-bounces@ietf.org Mon Jun 18 13:20:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB07D11E8088; Mon, 18 Jun 2012 13:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340050827; bh=DYVsqwnKsvsbVaJzQjX8H2GMPdFzxh049yGi/ikfaP0=; h=Mime-Version:From:Date:Message-Id:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=XXz8OQekjBGyPV+dpQ528QhA23qmWvTqcgx/9C7m/RCwjn02APxrVV4ZdKuOx+dWX m6xaF2L9kqILh1ZHxfZIrweaYJ0O348rRvRN4T9FR7LD3RgbitPRDx6kUPGPVH2K44 RAv/19wFCR/2DSv+9VTdLkfgUSI0ych/EOUhWpEc= 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) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 address for the host on the Internet. DNS automatically translates the domain name into IP address when user accesses Internet using domain name. 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 name is consist of its internal domain name and its AIP network default domain name suffix. should read Any IP node's external domain name consists of its internal domain name and its AIP network default domain name suffix. 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? _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 16:19:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7811E80D5; Mon, 18 Jun 2012 16:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340061582; bh=6Kg7b5Olu4Gs/nkTnv6+Fh3r//U65zoy+j4T20jv79w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=B3wmdIK34LfsPZEUIY/2YpMVkpCzjtBbh9NoxFQTgTMC/PDfVAM64yYnfLOxb74UY ay7nneXdxwBtcLqyrgwIKgI4JrCBFZklLQsIkk3nJnR8ETUJBVPe2TKWNnGqaUvcbX 1whHPP1XVK7Ket9Z5AXcAzhRAjDtlKwn6x0Z8vTQ= 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==?= 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: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 16:50:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7221211E809A; Mon, 18 Jun 2012 16:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340063420; bh=C58/8CCHMB04Y1cSEpMSEWiAyYC5nfb5YZqbsOy11Ew=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=j8VUS9sCgVNT72zhPvD9m8hh0rOJ7j68yqpHFJkJSSO+de1IidaaBOnTMOWRGe2cX ogEu8aMbFq/hh9/r+PykPulvuz+VoIzG6/03Ze/aXlFCWT7ZNVSh9018jRo9TRvJFf M4XiL0mams74mfXb4UClhsiHQGqV1IX4U0CiEA2g= 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) From: Ralph Droms In-Reply-To: Date: Mon, 18 Jun 2012 17:50:16 -0600 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Ck9uIEp1biAxOCwgMjAxMiwgYXQgNzoyOSBBTSA2LzE4LzEyLCBPbmTFmWVqIFN1csO9IHdyb3Rl OgoKPiAKPiBPbiAxOC4gNi4gMjAxMiwgYXQgMTU6MTIsIFN0ZXBoYW5lIEJvcnR6bWV5ZXIgd3Jv dGU6Cj4gCj4+IE9uIE1vbiwgSnVuIDE4LCAyMDEyIGF0IDAyOjU4OjMxUE0gKzAyMDAsCj4+IE9u ZD9laiBTdXLDvSA8b25kcmVqLnN1cnlAbmljLmN6PiB3cm90ZSAKPj4gYSBtZXNzYWdlIG9mIDM1 IGxpbmVzIHdoaWNoIHNhaWQ6Cj4+IAo+Pj4gVW5pZmllZCBETlMgdHJlZSB3YXMgYW5kIGlzIGFu IGltcG9ydGFudCBidWlsZGluZyBibG9jayBvZiB0aGUKPj4+IEludGVybmV0IGFuZCBzdGFuZGFy ZGl6aW5nIEROUy1zcGxpdCB3b3VsZCBtZWFuIHRoZSBlbmQgb2YgdGhlCj4+PiBJbnRlcm5ldCBh cyB3ZSBrbm93IGl0Lgo+PiAKPj4gVGhlIEktRCBkb2VzIG5vdCBzcGxpdCB0aGUgRE5TIGF0IGFs bC4gSXQgcGxheXMgd2l0aCB3b3JkcyBieQo+PiBwcmV0ZW5kaW5nIGl0IHdpbGwgYWxsb3cgc2V2 ZXJhbCByb290cyBidXQgdGhpcyBpcyBub3QgdHJ1ZS4gSW5zdGVhZCwKPj4gaXQgY3JlYXRlcyBh IHN1cGVyLXJvb3QgKHRoZSBvbmUgd2hpY2ggd2lsbCBhbGxvY2F0ZSB0aGUgQUlQcywgdGhlIC5B Cj4+IGFuZCAuQiBpbiB0aGUgZXhhbXBsZXMpIGFuZCB0aGVyZWZvcmUganVzdCBkaXNwbGFjZXMg dGhlIChyZWFsKQo+PiBwcm9ibGVtcyB0byB0aGUgc3VwZXItcm9vdC4KPiAKPiBXZWxsLCB5ZXMg YW5kIG5vLiAgSXQncyBzb21ldGhpbmcgaW4gYmV0d2Vlbi4KPiAKPiBJZiB5b3UgYXJlIGluICcu QScgQUlQLCB5b3Ugd2lsbCBub3QgaGF2ZSB0byB0eXBlIC5BIGF0IHRoZSBlbmQgb2YgeW91cgo+ IHF1ZXJ5LCBzbyBnb3YuY24gd2lsbCB3b3JrIGFzIGlzIHdpdGhvdXQgJy5BJy4gIE9ubHkgaWYg eW91IHdhbnQgdG8gZ28KPiB0byAndW5hcHByb3ZlZCcgc2l0ZSBpbiAuQiB0cmVlIHlvdSB3aWxs IGhhdmUgdG8gdHlwZQo+ICdlbmNyeXB0ZWQuZ29vZ2xlLmNvbS55b3Utd2lsbC1iZS1hcnJlc3Rl ZCcgaW50byB5b3VyIGJyb3dzZXIgVVJMIGJhci4KCkkgYWxzbyB0aGluayB0aGF0IGlmIHlvdSBx dWVyeSBleGFtcGxlLmNvbSAod2l0aCBubyAuKiBzdWZmaXgpIGluIHJlYWxtIEEsIHlvdSBtYXkg Z2V0IGEgZGlmZmVyZW50IGFuc3dlciB0aGFuIGlmIHlvdSBxdWVyeSBleGFtcGxlLmNvbSBpbiBy ZWFsbSBCLgoKLSBSYWxwaAoKPiAKPj4gVGhpcyBpcyB3aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9m ICJzZXZlcmFsIHJvb3RzIiBzeXN0ZW1zIGRvOiBjcmVhdGUgYQo+PiBuZXcgcm9vdCBidXQgZG8g bm90IGNhbGwgaXQgYSByb290LiBOZXdzcGVhayBhdCBpdHMgYmVzdC4uLgo+IAo+IAo+IFl1cCwg SSBhZ3JlZS4KPiAKPiBPLgo+IC0tCj4gT25kxZllaiBTdXLDvSAtLSBDaGllZiBTY2llbmNlIE9m ZmljZXIKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gQ1ou TklDLCB6LnMucC5vLiAgICAtLSAgICBMYWJvcmF0b8WZZSBDWi5OSUMKPiBBbWVyaWNrYSAyMywg MTIwIDAwIFByYWhhIDIsIEN6ZWNoIFJlcHVibGljCj4gbWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5j eiAgICBodHRwOi8vbmljLmN6Lwo+IHRlbDorNDIwLjIyMjc0NTExMCAgICAgICBmYXg6KzQyMC4y MjI3NDUxMTIKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBkbnNl eHQgbWFpbGluZyBsaXN0Cj4gZG5zZXh0QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbnNleHQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Mon Jun 18 17:01:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8FE11E80F1; Mon, 18 Jun 2012 17:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340064079; bh=HlS0hkkz1p+ufPuOViFbJEfFmDQzLqhCYajgGoTpP2c=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Sender; b=foJbFezh+aVA4vjspl6YUC/g3xCUnKapWmrtSKCVbqarolaTk9ige/Qd6542nqNWA /1iy9R8Lu2T5XipBIEmxMFWLkSryQR/1GYXGwxZ5xx1DccYBAwE++q6lQk3Alxqvyt wyyjp24Uxf1655nwmk7KPa4BtWSULXkaAvpdnm5E= 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: , MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1433759660005832141==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============1433759660005832141== Content-Type: text/plain 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 --===============1433759660005832141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============1433759660005832141==-- From dnsext-bounces@ietf.org Mon Jun 18 17:54:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156D21F85FB; Mon, 18 Jun 2012 17:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340067247; bh=VrXSJDYz8RuAKaNzFFlvhJdJEIQId33cAlZRk/V3UgQ=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QN7cycZiQ06Pkv7hDuA3uWsE4QBwlIWzyNbZ/z8ltMnsPdxL47uc88WYiDyXdmWlv eKk/qPAOrr2QuVCpTX8H8EZf4LnmDRQJ1TWlU6O3yChGYFw0GtD3i33FbRFZoAcGJf HgQqhOOF/dR4FKT+XLgLAon6lLTRhFS6+RBl7tLk= 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) From: Warren Kumari In-Reply-To: Date: Mon, 18 Jun 2012 20:54:08 -0400 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Ck9uIEp1biAxOCwgMjAxMiwgYXQgODo1OCBBTSwgT25kxZllaiBTdXLDvSB3cm90ZToKCj4gSGks Cj4gCj4gdGhhbmtzIFRvbnkgZm9yIHBvaW50aW5nIHRoYXQgb3V0Li4uCj4gCj4gT24gMTcuIDYu IDIwMTIsIGF0IDE5OjAxLCBUb255IEZpbmNoIHdyb3RlOgo+IAo+PiBTbyB0aGlzICJETlMgRXh0 ZW5zaW9uIGZvciBBdXRvbm9tb3VzIEludGVybmV0IiBjYXVnaHQgbXkgZXllLiBUaGVyZSBhcmUK Pj4gY2xlYXJseSBhIG51bWJlciBvZiBhdXRvbm9teS1yZWxhdGVkIHJlcXVpcmVtZW50cyB0aGF0 IHRoZSBETlMgZG9lcyBub3QKPj4gc2F0aXNmeSwgc3VjaCBhcyBwcml2YXRlL2ludGVybmFsIG5h bWVzIGFuZCBhZC1ob2MgbmV0d29ya2luZy4gVGhlc2UgYXJlCj4+IGN1cnJlbnRseSBzYXRpc2Zp ZWQgYnkgd29ya2luZyBvdXRzaWRlIHRoZSBhcmNoaXRlY3R1cmUgLSBCSU5EJ3Mgdmlld3MgYW5k Cj4+IG11bHRpY2FzdCBETlMgcmVzcGVjdGl2ZWx5Lgo+PiAKPj4gSG93ZXZlciB0aGlzIGRyYWZ0 IGlzIG5vdCBhYm91dCBhbnkgb2YgdGhhdC4gSXQgYXBwZWFycyB0byBiZSBwcm9wb3NpbmcgYQo+ PiB0ZWNobmljYWwgd29ya2Fyb3VuZCBmb3IgZGlzc2F0aXNmYWN0aW9uIHdpdGggSUNBTk4ncyBt YW5hZ2VtZW50IG9mIHRoZQo+PiBETlMgbmFtZXNwYWNlLgo+IAo+IEkgYW0gbm90IHNvIHN1cmUg YWJvdXQgdGhlIG1vdGl2YXRpb25zLCBidXQgSSBzZWUgdGhpcyBkcmFmdCBhcyBkYW5nZXJvdXMK PiBwcmVjZWRlbnQuICBVbmlmaWVkIEROUyB0cmVlIHdhcyBhbmQgaXMgYW4gaW1wb3J0YW50IGJ1 aWxkaW5nIGJsb2NrIG9mIHRoZQo+IEludGVybmV0IGFuZCBzdGFuZGFyZGl6aW5nIEROUy1zcGxp dCB3b3VsZCBtZWFuIHRoZSBlbmQgb2YgdGhlIEludGVybmV0Cj4gYXMgd2Uga25vdyBpdC4KPiAK Pj4gQnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgbm9uZSBvZiB0aGlzIGlzIG5lY2Vzc2FyeTogYWxs IGl0IGlzIGRvaW5nIGlzIHNoaWZ0aW5nIHRoZSBuYW1lc3BhY2UgZG93biBhIGxldmVsLgo+IAo+ IAo+IEV4YWN0bHkuICBBbmQgdGhlbiBpdCB3b3VsZCBiZSBqdXN0IGEgbWVzcyAtIGV2ZXJ5IGNv dW50cnkgd291bGQgY3JlYXRlIGl0J3Mgb3duIEludGVybmV0Lgo+IAo+PiBUaGF0IGlzIHlvdSBj YW4gZ2V0IGEgc2ltaWxhciByZXN1bHQgWy4uLl0gdXNpbmcgZXhpc3RpbmcgdGVjaG5vbG9naWVz Lgo+IAo+IAo+ICsxCj4gCj4gbm90IHRoYXQgSSBwcm9tb3RlIHRoZSB1c2FnZSBvZiBleGlzdGlu ZyB0b29scyBmb3IgSW50ZXJuZXQgY2Vuc29yc2hpcCwKPiBidXQgYXQgbGVhc3QgdGhvc2UgYXJl IGp1c3QgdG9vbHMsIGFuZCBub3QgdGhlIGp1c3RpZmljYXRpb24gdG8gc3BsaXQKPiB0aGUgSW50 ZXJuZXQuCj4gCj4gTGFzdCwgYnV0IG5vdCBsZWFzdCwgd2UgKElFVEYpIHNob3VsZCBwcm9kdWNl IHRlY2huaWNhbCBkb2N1bWVudHMKPiBhbmQgbm90IHBvbGl0aWNhbC4gIFRoaXMgaXMgcXVpdGUg bmljZSBleGFtcGxlIG9mIGEgZG9jdW1lbnQgd2hpY2gKPiAoaW4gbXkgdmlldykgcHV0cyBwcmlv cml0aWVzIG9mIG5hdGlvbmFsIHN0YXRlcyBvdmVyIHRoZSBvcGVubmVzcwo+IGFuZCBvdmVyYWxs IGNvbXBhdGliaWxpdHkgb2YgdGhlIEludGVybmV0LgoKSGVhciBoZWFy4oCmLgoKVGhlcmUgYXJl IGEgbGFyZ2UgbnVtYmVyIG9mIG1ham9yIGlzc3VlcyB3aXRoIHRoZSBkb2N1bWVudCAoYXBhcnQg ZnJvbSBsZWdpYmlsaXR5KSwgYnV0IHRoZSBhZGRlZCBjb21wbGV4aXR5IGFuZCBmcmFnaWxpdHkg Zm9yIHNvbWVvbmUncyBuYXRpb25hbGlzdGljIGRlc2lyZXMgYXJlIG5vdCBhIHJlYXNvbmFibGUg dHJhZGVvZmYuCgpJIHdhcyBhbHNvIG11Y2hseSBlbnRlcnRhaW5lZCBieSB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgYW5kIElBTkEgQ29uc2lkZXJhdGlvbnMgYml0cyAtLSB3aGVlZSwgbGV0 cyBieXBhc3MgdGhlIGV4aXN0aW5nIChmbGF3ZWQpIHByb2Nlc3MgYW5kIGdldHMgb3VyIG93biBz dHJpbmcgYnkgcHVibGlzaGluZyBhIGRvY+KApgoKVwoKCj4gCj4gTy4KPiAtLQo+IE9uZMWZZWog U3Vyw70gLS0gQ2hpZWYgU2NpZW5jZSBPZmZpY2VyCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQo+IENaLk5JQywgei5zLnAuby4gICAgLS0gICAgTGFib3JhdG/F mWUgQ1ouTklDCj4gQW1lcmlja2EgMjMsIDEyMCAwMCBQcmFoYSAyLCBDemVjaCBSZXB1YmxpYwo+ IG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogICAgaHR0cDovL25pYy5jei8KPiB0ZWw6KzQyMC4y MjI3NDUxMTAgICAgICAgZmF4Ois0MjAuMjIyNzQ1MTEyCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gZG5zZXh0IG1haWxpbmcgbGlzdAo+IGRuc2V4dEBpZXRmLm9y Zwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0CgotLSAKV2l0 aCBGZXVkYWxpc20sIGl0J3MgeW91ciBDb3VudCB0aGF0IHZvdGVzLgoKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5z ZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0 Cg== From dnsext-bounces@ietf.org Mon Jun 18 19:12:27 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88F11E80FE; Mon, 18 Jun 2012 19:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340071947; bh=EJwOaiUqKSLWMPXZuY7H15icFdu1ZzBBoejV2MLw9fw=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ji52M6KXaAxBVrFTnNhvtjhSGL9P3Y88KhW17Y2uldfMAJI5AgL7DVWeBuCKrr9+S x/Hg3geUsOuIWfyPZJ23XTMmosZLdQFxqD+2qTiSCfUEPUuP3LfzJOMNIM5+CwE7vC euJBdC7Jd1QZt51vgoThr03zva7ZI9q5nVrOKaTI= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 19:30:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F921F85AD; Mon, 18 Jun 2012 19:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340073040; bh=0fYyZKOACAYx3n7UV/8dxGF6OWOQ+ftu3+YyRVys8aQ=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ecRujurj0VDs85aHrGCNtVeyBcwQTjM0MJyA2CxhDBfELLTl4I5h+Z800G1sDN9BC hvrXWgPOh1dBmFmAvlpSAm1gRVbpA09YTMVG3FYfw8d0ZAUHc+MzucQkUFHpur7tIS akWbaxZmeKX54K/kYtMJWrCyqUFAj+3CEQGGzLg0= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 18 19:49:50 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06BA11E80A3; Mon, 18 Jun 2012 19:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340074190; bh=VUAdrXo7OWQEtla51YCgUJwCRHP1ORT8FRsh0QCcoms=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=plRWGgKDxiBRt7fK3OKsVSl/fumF2qhfZE9kbTMOvRtfq6soRwHNJmu/w7UDxBtkQ BN0EXh3VM+j3hOQXdtIqvUBLUwuBbasx6UeANiGc717/TLEYtXFOvnr7i2YLgD7+gO q3JQ/kmxdLbcuLuVIT9AiJ9MAr0uwuaz9IDs+uD4= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 19 02:37:51 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9721F85C7; Tue, 19 Jun 2012 02:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340098671; bh=8kygg1co8skeBpXn3rQCKkqTZAIuGgjxoJXxymoL1bo=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lCaclag/FJrdzY7bB5I22j+ZHN8Jsl29o9bKyLuNbgFzCs431yslNWL8bTx0z48v9 51RaN9l4qVJHpckitylI2FJIisJtnQNJpQrjGuFQaH3Rsf8VI9SYxm3l5IqYFzP8Qa y9OAv+mh3R1rifXjWP8SDRPM+wAUu7OUvCviF/50= 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-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 19 08:34:17 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128E111E80BD; Tue, 19 Jun 2012 08:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340120057; bh=hQT7kD6vMl8vF47O2i01A//H/ynfrXwUn/4ZRbWbOro=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=XMCKamkNlb8CxvSr5G1aATr65o4bwsRQM3wpKBHyOLH2as7Z3mAZsxwE/ZlylZv/h hoGnXZUDXKqc+J0sJ23TKmQ+RSh6VjNk9YgwHA44pq5o7fPSaAPnPbibDaSSJjErnr c0VTMBE+pMmqLDiH6AFqA0HdWQwXQVdf7W2qQ6cw= 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 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 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org T2xhZnVyLAoKSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtZG5zZXh0LXJmYzYxOTViaXMtMDIg YW5kIG9mZmVyIHRoZQpmb2xsb3dpbmcgb2JzZXJ2YXRpb25zOgoKClszLjEgcGFyYWdyYXBoIDRd CmFuZCBbMy4yIHBhcmFncmFwaCA0XQoKUmVnZXhlczoKCiAgICAgICAgICAgICAgICAgICAgICAg ICBbQS1aXVtBLVowLTlcLV0qW0EtWjAtOV0KCiAgICAgICAgICAgICAgICAgICAgICAgIChUWVBF fENMQVNTKSgwfFsxLTldWzAtOV0qKQoKY291bGQgYmUgc2ltcGxpZmllZCB0bzoKCiAgICAgICAg ICAgICAgICAgICAgICAgICBbQS1aXVtBLVowLTldKgoKICAgICAgICAgICAgICAgICAgICAgICAg KFRZUEV8Q0xBU1MpWzAtOV0qCgoKUHJldmlvdXMgUkZDIGF1dGhvcnMgaGF2ZSBhYnN0YWluZWQg ZnJvbSB1c2luZyB0aGUgaHlwaGVuIHdoZW4Kc3BlY2lmeWluZyBSUlRZUEUgYW5kIENMQVNTIG1u ZW1vbmljcy4gUmVnZXggMSBzaG91bGQgY29uc3RyYWluIGZ1dHVyZQphdXRob3JzIGFuZCBJQU5B IHRvIGZvbGxvdyBlc3RhYmxpc2hlZCBjdXN0b20gYW5kIHByYWN0aWNlLiBUaGUgb25seQpoaXN0 b3JpY2FsIGV4Y2VwdGlvbiAoTlNBUC1QVFIpIGxpdmVkIHF1aWV0bHkgaW4gUkZDMTM0OCBhbmQg YmVjYW1lCm9ic29sZXRlIGluIDE5OTQuCgpSZWdleCAyLCBhcyB3cml0dGVuLCBmYWlscyB0byBt YXRjaCB1bmtub3duIHR5cGUgYW5kIGNsYXNzIGlkZW50aWZpZXJzCmhhdmluZyBsZWFkaW5nIHpl cm9lcyBpbiB0aGUgbnVtZXJpYyBwYXJ0LCB3aGljaCBpcyBub3QgZXhwbGljaXRseQpkaXNhbGxv d2VkIGJ5IFJGQzM1OTcuICBJTUhPIHRoZSBtbmVtb25pY3MgQ0xBU1MgYW5kIFRZUEUgKG5vIGRp Z2l0cykKc2hvdWxkIGFsc28gYmUgZGlzYWxsb3dlZCB0byBhdm9pZCBhY2NpZGVudGFsIGluZ2Vz dGlvbiBvZgpwbGFjZS1ob2xkZXJzIGlmL3doZW4gYW55IHBhcnQgb2YgdGhpcyBwcm9jZXNzIGJl Y29tZXMgYXV0b21hdGVkLgoKCgpEaWNrCgoKCgoKT24gMTEgSnVuZSAyMDEyIDE4OjQzLCBPbGFm dXIgR3VkbXVuZHNzb24gPG9ndWRAb2d1ZC5jb20+IHdyb3RlOgo+Cj4KPgo+IERlYXIgY29sbGVh Z3Vlcwo+Cj4KPgo+IFRoaXMgbWVzc2FnZSBzdGFydHMgYSAyIHdlZWsgV0dMQyBmb3IgUkZDNjE5 NWJpcyBlbmRpbmcgYXQgbWlkbmlnaHQgVVRaIEp1bmUgMjgndGggMjAxMi4KPgo+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zZXh0LXJmYzYxOTViaXMtMDIKPgo+Cj4K PiBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyBrbm93biBmbGF3cyBpbiB0aGUgUkZDNjE5NSAoc2Vl IGFwcGVuZGl4IEEpLgo+Cj4KPgo+IFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwb3N0 IGEgbm90ZSB0aGF0IHlvdSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCB3ZSBuZWVkIGEgbWlu aW11bSBvZiA1IHJldmlld2Vycy4KPgo+Cj4KPiAgwqAgwqBPbGFmdXIgJiBBbmRyZXcKPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4KPiBkbnNleHQg bWFpbGluZyBsaXN0Cj4KPiBkbnNleHRAaWV0Zi5vcmcKPgo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KZG5zZXh0IG1haWxpbmcgbGlzdApkbnNleHRAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQK From dnsext-bounces@ietf.org Tue Jun 19 10:23:14 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B00811E80E8; Tue, 19 Jun 2012 10:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340126594; bh=MRrxjblEF7VEcAqXq19u+buuLLUFXo8cJNLNED8eVFw=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QJ9YpAtxCrQxRznRT9ZdruHzX3kjSY0w52ECSCAt7X9hMywprmfuJrHir88u2f47B /7ht547lZfTRtb0aAlji6ZX084LVH6YPgseImNBKI5i/bwarry8PnFz9RKbv+dn/B+ 3w8eFGp6v3/PjpYggiPXlhhLQC5+kbtLKIP0ndOY= 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) From: Ralph Droms In-Reply-To: <20120619093656.GA24383@nic.fr> Date: Tue, 19 Jun 2012 11:23:05 -0600 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 19 18:52:58 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85C11E80C1; Tue, 19 Jun 2012 18:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340157178; bh=Mzb726gYKWIWdG4GReJPAd6oGe+kzLnhkM0oFufu50E=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=KR8GKGM449JnYh7yylNwSxOFlC+5iKcixSvoz4i9zxZ4RuIr5khkfBHn8AXGd+5v7 eMv6QG8j2yBzyAe0MlEW3hCAtVtS1pVta58ZccG4DIRjI3xb3Tnm65UX9NwMPSiLPC xFAMjaesR76eNdSd3fE3bnal5hnmGnc6ICWXJiXY= 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Jun 20 00:42:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5D21F8714; Wed, 20 Jun 2012 00:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340178179; bh=1py4fIZeA2PLBOx7nAbIlW43nr47ncgid/DSsaXQkXc=; h=Message-Id:Date:To:From:In-Reply-To:References:Mime-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=A93TouSdHk0aVrwJb2n87s9MP5SgiSh/5VJ6+Xve0f9Y6T9bBP7jWULVMcdc/4OPq JAvXHs5WQDjBnJVsIpuoF+G5C/FwbrqUr/yLKWR1oVzF8DwG9ez7GCP0pP6fSYtfsA r2DmWCGaVPqI4HxbCU8CurrUClezv7+7zi/qw5/4= 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Jun 20 08:31:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2D21F85E5; Wed, 20 Jun 2012 08:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340206309; bh=5eJqhoAP/kI/Ke3D8pz5rMIb+4YRMm0f0WN/ezO6NNg=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=bb74l2/5kegk/i/+g2deUiS4zKFmwS5k5AyqqinUGCrK19DnWn3kkeN2gq7X9AJfh LZTZUw8RTfkLV4mtlXYtj9Ap6fOZDK7PIQQN/6s8TvtuC0iWQ0pMGUTbO+UReLMwrj 75RQ68WVq1VjzMbpn03gNSa1Ws2MzZfZauoxuHmc= 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) From: Nicholas Weaver In-Reply-To: Date: Wed, 20 Jun 2012 08:31:44 -0700 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org My own $.02 as well, on just one little piece... > 5. Security Considerations > > 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. 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 ?= 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. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Jun 20 13:16:18 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB5C21F864B; Wed, 20 Jun 2012 13:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340223377; bh=scXRJU9CHP61+qUmOqtcu9BcANBqwqnvIJOzdFaVvLg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=N50uc9HaSA7iX6LwPh2pN4s0gKqVXDeysq8YU0tZmlufVrdId2PUH7bbdHUqQIN7T AprbumbD/uHTsGBCoSXKFr2uLajYW+8ZYp4Y3QWvFdRZpZpMlKfQ4sf395rL63ylzo 0U5l4b78LvCHqJ0TUom3Qr2aBwzykGBcwc0UezkI= 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 Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nicholas Weaver References: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu> In-Reply-To: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu> X-Enigmail-Version: 1.4.2 Cc: draft-diao-aip-dns@tools.ietf.org, 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 06/20/2012 08:31 AM, Nicholas Weaver wrote: > The point of this is to allow a country to "override the root" s/the root/ICANN/ ... where overriding the root is just a tool. It should be pretty obvious where I stand on this, but for the record, I'm vehemently opposed to the draft (speaking only for myself of course). Doug _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 21 05:45:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF621F85D9; Thu, 21 Jun 2012 05:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340282752; bh=zTodm9/ddsH3vQZXiczmDDFLiN1nXFi44JEvrwlQhOg=; h=Message-ID:From:To:References:Date:MIME-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=CDv4h7aclnda2pKMEa1dmkrNtM5kIuaPZGwiZ5zpWjQ51lM8d1THFPStrE5DyXcLu uIB7Rlefy4RxapyPHVccOmaTrZWiwT882DUcnp9hzREC0n/2233G0psSevnv5I0Idp h2fn2PLXphOs2axCkPPoaE3sa0foSZiO9XTU41oY= 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 03EDE21F85D9 for ; Thu, 21 Jun 2012 05:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.615 X-Spam-Level: X-Spam-Status: No, score=-98.615 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, 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 qAAuo6jSq9yx for ; Thu, 21 Jun 2012 05:45:50 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id C468621F85DD for ; Thu, 21 Jun 2012 05:45:48 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 21 Jun 2012 20:45:41 +0800 Message-ID: <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , "S Moonesamy" References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> Date: Thu, 21 Jun 2012 20:45:36 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: iesg@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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org ----- Original Message ----- From: "Andrew Sullivan" To: "S Moonesamy" Cc: ; ; ; Sent: Tuesday, June 19, 2012 10:30 AM Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 > ...... >> 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. > SM does not mean seven years is a rush. He mean that this draft survives almost 7 years and the draft has not clear clue of being ready to be published before announcement of DNSEXT WG shutting down. Only after the announcement, someone said that this draft is ready for publication. Many readers, I think it is not only SM, feel that there is a little surprise or unexpected. >From 0 month to 6 year and 11 month, there is no sign of ready. >From 6 year and 11 month to 6 year and 12 month, suddently say that "it is ready to go" This is a rush, not 7 years as a rush. If I understand SM correctly, I think That is why there is a rush. Jiankang Yao _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 21 07:03:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668FD21F8692; Thu, 21 Jun 2012 07:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340287396; bh=f2nT6asTwXgyFW0vREhHJJb5nGdqg53xi2WnJmsUqTM=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=GvadacgWZIvExPlB6M0h4SWwVZrebt5lPfR2yQUANeIBjd7lgTu1rOOJbZLarENmO mpZiNTku5b3dux9GDyIF4IsrB8wVToSFEoKtLGHfLZ4hDinQYdmoxbia5wVnT/OWP0 jZtDsyfFbfW/l7GeenextW1gkZAyf+JOdlttdKAI= 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 6646A21F8692; Thu, 21 Jun 2012 07:03:13 -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 fCOLPcNV0NnG; Thu, 21 Jun 2012 07:03:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95E21F8690; Thu, 21 Jun 2012 07:03:10 -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 18F821ECB41D; Thu, 21 Jun 2012 14:03:09 +0000 (UTC) Date: Thu, 21 Jun 2012 10:03:01 -0400 From: Andrew Sullivan To: Jiankang YAO Message-ID: <20120621140301.GA42780@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, S Moonesamy , apps-discuss@ietf.org, iesg@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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Thu, Jun 21, 2012 at 08:45:36PM +0800, Jiankang YAO wrote: > He mean that this draft survives almost 7 years and the draft has not clear clue of being ready to be published before announcement of DNSEXT WG shutting down. I see. With respect, I think I must have said about thirty times over the past several years, "It is time to get this document published." The minutes from meetings at IETF 77 and IETF 78 both say that it seems time to publish the document, just for example; I haven't even looked at the list arhives. SM was not an active participant in DNSEXT for much of that time, so he might well have overlooked those previous discussions. Did you miss them also? I will cheerfully accept responsibility for having failed to press hard enough. I nevertheless object to the characterization of "rush". It's simply not true. This document has been pursued in the most leisurely way possible. Best regards, Andrew (as shepherd) -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 22 11:11:23 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4011E8080; Fri, 22 Jun 2012 11:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340388683; bh=ifWiSXHMo+0rAyb0IBlkHYU06QYfBx1V/rHkGVcSxxY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=P5aBVd4lwPKutnh2jDbVecvZK22c4pPEIVqoq8YfPjc3Q/4fU2TuxbbWPjVD96YC4 y1+DvQLNsk0SkXAvOHus9z3DAq6XIrIcTb7oyQFAk4+8TmxdsoaV4tuqTA4Bqa48rn UKG736r9BQM9d7EWI0AR1FAqISLQuVL8izOysxLM= 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 47AE011E8080 for ; Fri, 22 Jun 2012 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 lSPmB8YfMD2O for ; Fri, 22 Jun 2012 11:11:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEF021F871C for ; Fri, 22 Jun 2012 11:11:18 -0700 (PDT) Received: by yenq13 with SMTP id q13so1953192yen.31 for ; Fri, 22 Jun 2012 11:11:17 -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=vDyNAKSQlpZhJ6X+XEGdloJbI8Y7TH1aoLWS8SMwBWI=; b=WERs1DpkuIs0AKknaXVm1oUDvD2x18Q6Q+GbpG+HPhIy8x4DKUbBu8VQ8xBH7pBxC6 e/yOIwp39iYsN8jWX2n0XnDnOQqYCvqQviUeUjMctrOhPe9PbLB20YII3VA39ccORb1g b/CDLWl2WDHf8eHGXWbHlF1O/eo/QvQjCKKJ5U2wf4WkqgAMJebKYY9I4Mpi7xPNiTD6 8kyiGaZ7lLKQd5KVcdvKutCfjzNOyhhW3sUHqbyxoeQcFdOnrkxum9oOFzJYMPGJyTGb ooNGAS1Rr4I11FiJF5Y5rbUdez/wR2UWbykKyZUXtFbrek9i+35DKI9pdKQ6JpytPHDA Ux1w== Received: by 10.50.212.98 with SMTP id nj2mr2622286igc.35.1340388677446; Fri, 22 Jun 2012 11:11:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Fri, 22 Jun 2012 11:10:57 -0700 (PDT) In-Reply-To: References: <4FD62E4E.4020007@ogud.com> From: Donald Eastlake Date: Fri, 22 Jun 2012 14:10:57 -0400 Message-ID: To: Dick Franks Cc: dnsext@ietf.org, Olafur Gudmundsson 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi Dick, On Tue, Jun 19, 2012 at 11:33 AM, Dick Franks wrote: > Olafur, > > I have reviewed draft-ietf-dnsext-rfc6195bis-02 and offer the > following observations: > > > [3.1 paragraph 4] > and [3.2 paragraph 4] > > Regexes: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [A-Z][A-Z0-9\-]*[A-Z0-9] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(TYPE|CLASS)(0|[1-9][0-9]*) > > could be simplified to: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [A-Z][A-Z0-9]* > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(TYPE|CLASS)[0-9]* That's not simplification, that's change. > 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. I believe that internal hyphens should be allowed within RRTPE and CLASS mnemonics. We do not know what future mnemonics or sets of mnemonics will be required. Better to remain more flexible here. > 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. =A0IMHO 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. I have no problem with making the Regex 2 exclusion slightly stronger so going with your changed Regex 2 is fine with me. 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 > 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 = June 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 do= cument we need a minimum of 5 reviewers. >> >> >> >> =A0=A0 =A0Olafur & Andrew >> >> _______________________________________________ >> >> dnsext mailing list >> >> dnsext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsext >> _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 22 13:54:47 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682C821F8533; Fri, 22 Jun 2012 13:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340398487; bh=GN/AqACHwf+kbWzb3tReuykc+rDeckhgo+eQfD8ssUE=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=pmgE0R1Uzfr0/dgbvi+WgUCYlQq2wivNDF6U4TgZ6sFRuVWiBuwoAdx9xjnrZQeC/ j9jhQ8zj8hGjLBr3Qgao8qrytXmrGrCRjgg7MIslxDR9M3odGM9WbaabWh/PvrZqKs AIWb5KxWdLcU8bpekG2EfAS3TCFmqvUzfcmJUio8= 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 D7FFD21F8533 for ; Fri, 22 Jun 2012 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.412 X-Spam-Level: X-Spam-Status: No, score=-10.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 5esKW5+NmJI4 for ; Fri, 22 Jun 2012 13:54:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1E621F852D for ; Fri, 22 Jun 2012 13:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=4153; q=dns/txt; s=iport; t=1340398485; x=1341608085; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=12nauOtv00F5jvvf8MqDI78MPhi0dBj+hfoFzDbRGvY=; b=VdULkUwSQYN1pS93WTxMmdNPs44s5kmzs9dmEx0IXd4h+f8nWDyb1cGw lLlVJw9Lw0cJZckWgj9R/d0+lqZ2IPQlANuB/FK/jMCx0foWWgOgd+Je0 eKS606oRm7oCZIKmuuMn3d63IguvmOeJGwlTDV/o4DcqwUx/o52itc4ax M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFDb5E+tJXG//2dsb2JhbABFtWeBB4IZAQEEEgFYHgsSNEkOBhMaCIVvgXoLmiiPFpBaBIsuG4UHYAOVLI4bgWaCe4FD X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="95079992" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jun 2012 20:54:44 +0000 Received: from rtp-rdroms-8916.cisco.com (rtp-rdroms-8916.cisco.com [10.116.164.55]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5MKsg7k030538 for ; Fri, 22 Jun 2012 20:54:44 GMT Mime-Version: 1.0 (Apple Message framework v1278) From: Ralph Droms In-Reply-To: <4FE22F87.90004@dougbarton.us> Date: Fri, 22 Jun 2012 16:54:42 -0400 Message-Id: <068460E5-B7EE-4A27-AFAC-3266DD2574A4@cisco.com> References: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu> <4FE22F87.90004@dougbarton.us> To: dnsext List X-Mailer: Apple Mail (2.1278) 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org FYI - reposted to the IESG by Stephen Farrell: Chinese Operators Hope to Standardize a Segmented Internet Posted on Monday Jun 18, 2012 10:20 AM by Mikael Rickn=E4s A technology draft written by employees at China Mobile and China Telecom and submitted to the Internet Engineering Task Force describes how the Internet could be split into several parts using the Domain Name System and in the process give countries more control over their own segment of the network. The DNS is one of the key building blocks of the Internet. Its most important task is translating IP (Internet Protocol) addresses to host names, which is done by a distributed system based on one unique root that is used all over the world. The technology is developed by the IETF, on whose website the Chinese "DNS Extension for Autonomous Internet" draft is available for viewing. Today, China blocks Internet access to some foreign websites. The goal outlined by the new document is to make it easier and cheaper for countries to create independent root DNS servers and realize Internet autonomy. Today, that is both costly and technically difficult, according to the draft. "When you read the document it very much comes across as a way to severely segment the Internet," said Patrik Wallstr=F6m, CEO at OpenDNSSEC AB, a not-for-profit company with the mission to facilitate the deployment of DNSSEC, which is used to secure DNS. If the draft is adopted it would give, for example, China full control of content on the Internet for users in the country as well as how it can be accessed and by whom, Wallstr=F6m said. The reason for adopting the draft into a standard architecture would not be just for control, according to the authors. The current central architecture of DNS can't keep up with the fast development of Internet, they say. That argument doesn't ring true, according to Jakob Schlyter, a DNS expert at Swedish consultancy Kirei. "When you say something like that you have to back it up with some facts, which I don't think they have ... the DNS root has an extreme overcapacity," said Schlyter. However, the chances of the draft being adopted is very remote, according to both Wallstr=F6m and Schlyter. Anyone can individually submit an Internet draft to the IETF. But since the intended goal with the Chinese document is standardization, it first has to be picked up by one of the IETF's working groups, and that isn't going to happen, Wallstr=F6m said. "It is a controversial subject, and the IETF works on standards that, in principle, are for the global Internet," said Wallstr=F6m. The idea of moving away from a central DNS root also goes against the IAB's (Internet Architecture Board's) technical comment from 2000, detailing the need for a unique DNS root to ensure the future of the Internet, according to Wallstr=F6m. The comment came after several alternative roots came into existence during the nineties, he said. "The Chinese draft would be a return to that," said Wallstr=F6m. Schlyter is equally convinced that nothing will become of the draft. "There is an extremely small risk of it going anywhere. I say risk because I am proponent of a common namespace, and all that comes with that," said Schlyter. Because of the minuscule chance of the draft ever becoming a standard, the underlying reason for publishing it may be something altogether different, according to Wallstr=F6m. "This is just me speculating, but with the arrival new generic top-level domains (gTLDs) a document like this one can be published to put more pressure on ICANN with the aim of maybe even splitting the organization into different parts where China has more power," Wallstr=F6m said. Today, ICANN (Internet Corporation for Assigned Names and Numbers), which is also a big proponent of a unique root, coordinates the DNS as well as a whole host of other Internet-related components. These were originally performed under a U.S. government contract. Send news tips and comments to mikael_ricknas@idg.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 22 19:27:02 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616D111E80B5; Fri, 22 Jun 2012 19:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340418422; bh=4sE2zNjgeEjRP92Rr7YKTugH9+J1XTy8hfH6Lw4lIdA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=GlPLvx3r4gnu1rp/Cu6SRj29zYjmvHVHt+cNgnERRLlcKZe/AgmdsMZErzR9610ar LOpYUs6ddJmxiaEH1RrdVwNiaouWknY2s4N8uQAAJwvZtqzA59rjHnvk416WqlKNlz qwnj0TLgqrMU40qhLyple2dRPtQRsKyFhBy9PPOw= 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 80ED211E80B5 for ; Fri, 22 Jun 2012 19:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_50=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 Q4pS8VR9v-6O for ; Fri, 22 Jun 2012 19:27:00 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 929AB11E80B3 for ; Fri, 22 Jun 2012 19:27:00 -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 q5MNH0t9065421 for ; Fri, 22 Jun 2012 19:17:00 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FE5296D.1030108@abenaki.wabanaki.net> Date: Fri, 22 Jun 2012 22:26:53 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 6/18/12 4:17 PM, Fred Baker wrote: > 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... I was there too Fred, speaking with Professor Qian Hua-lin and others, and Madame Hu Qiheng on the range of choices _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Jun 24 22:10:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1E21F855A; Sun, 24 Jun 2012 22:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340601029; bh=H4O7FtdxDnqXltduGqV08fGA0mS+/8owJr+A+bl5Nyw=; h=Message-ID:From:To:References:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=h0xUNufTE56TVceyDhosVm02nrJ6yXKlpALg+X7fje8J2/tHWtcRM7LvWyus6Bydt Y7w58EgdTqV1ezICyQ7VknE452pWFkqltRCCAlyKz6cAC1+CFD+oshHnB+uRuCe0Px 5jC4wIujqdeS9B8QJ3jCLaiPAo6Ip4cmcBQIm3Hg= 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 A08CA21F855A for ; Sun, 24 Jun 2012 22:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.524 X-Spam-Level: X-Spam-Status: No, score=-98.524 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, 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 5qvMvcpWbDqt for ; Sun, 24 Jun 2012 22:10:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8D6CA21F853D for ; Sun, 24 Jun 2012 22:10:22 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 25 Jun 2012 13:10:14 +0800 Message-ID: <4264D74FFF4B4173BE01E190C3C0A490@LENOVO47E041CF> From: "Jiankang YAO" To: "Ralph Droms" , "dnsext List" References: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu><4FE22F87.90004@dougbarton.us> <068460E5-B7EE-4A27-AFAC-3266DD2574A4@cisco.com> Date: Mon, 25 Jun 2012 13:10:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I just called one of china mobile friends, who said that China mobile headq= uarter did not know about this draft and the idea in this draft. They are t= rying to learn what the draft is and what the idea in this draft is. At lea= st, it is not the official idea from China mobile. Some colleagues from china mobile may respond to it later. Jiankang Yao ----- Original Message ----- = From: "Ralph Droms" To: "dnsext List" Sent: Saturday, June 23, 2012 4:54 AM Subject: Re: [dnsext] draft-diao-aip-dns FYI - reposted to the IESG by Stephen Farrell: Chinese Operators Hope to Standardize a Segmented Internet Posted on Monday Jun 18, 2012 10:20 AM by Mikael Rickn=E4s A technology draft written by employees at China Mobile and China Telecom and submitted to the Internet Engineering Task Force describes how the Internet could be split into several parts using the Domain Name System and in the process give countries more control over their own segment of the network. The DNS is one of the key building blocks of the Internet. Its most important task is translating IP (Internet Protocol) addresses to host names, which is done by a distributed system based on one unique root that is used all over the world. The technology is developed by the IETF, on whose website the Chinese "DNS Extension for Autonomous Internet" draft is available for viewing. Today, China blocks Internet access to some foreign websites. The goal outlined by the new document is to make it easier and cheaper for countries to create independent root DNS servers and realize Internet autonomy. Today, that is both costly and technically difficult, according to the draft. "When you read the document it very much comes across as a way to severely segment the Internet," said Patrik Wallstr=F6m, CEO at OpenDNSSEC AB, a not-for-profit company with the mission to facilitate the deployment of DNSSEC, which is used to secure DNS. If the draft is adopted it would give, for example, China full control of content on the Internet for users in the country as well as how it can be accessed and by whom, Wallstr=F6m said. The reason for adopting the draft into a standard architecture would not be just for control, according to the authors. The current central architecture of DNS can't keep up with the fast development of Internet, they say. That argument doesn't ring true, according to Jakob Schlyter, a DNS expert at Swedish consultancy Kirei. "When you say something like that you have to back it up with some facts, which I don't think they have ... the DNS root has an extreme overcapacity," said Schlyter. However, the chances of the draft being adopted is very remote, according to both Wallstr=F6m and Schlyter. Anyone can individually submit an Internet draft to the IETF. But since the intended goal with the Chinese document is standardization, it first has to be picked up by one of the IETF's working groups, and that isn't going to happen, Wallstr=F6m said. "It is a controversial subject, and the IETF works on standards that, in principle, are for the global Internet," said Wallstr=F6m. The idea of moving away from a central DNS root also goes against the IAB's (Internet Architecture Board's) technical comment from 2000, detailing the need for a unique DNS root to ensure the future of the Internet, according to Wallstr=F6m. The comment came after several alternative roots came into existence during the nineties, he said. "The Chinese draft would be a return to that," said Wallstr=F6m. Schlyter is equally convinced that nothing will become of the draft. "There is an extremely small risk of it going anywhere. I say risk because I am proponent of a common namespace, and all that comes with that," said Schlyter. Because of the minuscule chance of the draft ever becoming a standard, the underlying reason for publishing it may be something altogether different, according to Wallstr=F6m. "This is just me speculating, but with the arrival new generic top-level domains (gTLDs) a document like this one can be published to put more pressure on ICANN with the aim of maybe even splitting the organization into different parts where China has more power," Wallstr=F6m said. Today, ICANN (Internet Corporation for Assigned Names and Numbers), which is also a big proponent of a unique root, coordinates the DNS as well as a whole host of other Internet-related components. These were originally performed under a U.S. government contract. Send news tips and comments to mikael_ricknas@idg.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 25 00:42:53 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0A21F8473; Mon, 25 Jun 2012 00:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340610172; bh=HLrVPbiBymQOVG3obodiw6WRfOXn0iFvLWfGmuQnKro=; h=Message-ID:From:To:References:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=K7ALrU9NvfId6n0iMyOz5Wr/fQt9i8rRZjgM18wX6E7mQOqrDnAWQOuql5Os1urVu JbbJL5ZqSX+F/NfIf4uuTHAZ+3AjsM89qRWhiM5WqSobHJKI8CGJBCHK7KQZW3/EZ/ IgewFmHwT/kgfCpdB5C2dpNvhmD0LdLY8UBUJKu4= 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 2CB8D21F84DE for ; Mon, 25 Jun 2012 00:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.783 X-Spam-Level: X-Spam-Status: No, score=-98.783 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, 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 0GJEL6ybT7Hj for ; Mon, 25 Jun 2012 00:42:47 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 28EE721F846D for ; Mon, 25 Jun 2012 00:42:45 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 25 Jun 2012 15:41:37 +0800 Message-ID: <7533FFDC51434AC2B7B741B238FA3577@LENOVO47E041CF> From: "Jiankang YAO" To: "Ralph Droms" , "dnsext List" References: <6FF8F3B1-D2B7-4C6B-B90D-245892D400EC@icsi.berkeley.edu><4FE22F87.90004@dougbarton.us><068460E5-B7EE-4A27-AFAC-3266DD2574A4@cisco.com> <4264D74FFF4B4173BE01E190C3C0A490@LENOVO47E041CF> Date: Mon, 25 Jun 2012 15:41:37 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I have talked to one of the authors for this draft, who said "this draft is= mainly due to individual research interests, it is not organiations' resea= rch interests." In 01 version, they have removed the organizaitons' name from the author in= formation. Pls see https://tools.ietf.org/html/draft-diao-aip-dns-01#page-11 Jiankang Yao ----- Original Message ----- = From: "Jiankang YAO" To: "Ralph Droms" ; "dnsext List" Sent: Monday, June 25, 2012 1:10 PM Subject: Re: [dnsext] draft-diao-aip-dns I just called one of china mobile friends, who said that China mobile headq= uarter did not know about this draft and the idea in this draft. They are t= rying to learn what the draft is and what the idea in this draft is. At lea= st, it is not the official idea from China mobile. Some colleagues from china mobile may respond to it later. Jiankang Yao ----- Original Message ----- = From: "Ralph Droms" To: "dnsext List" Sent: Saturday, June 23, 2012 4:54 AM Subject: Re: [dnsext] draft-diao-aip-dns FYI - reposted to the IESG by Stephen Farrell: Chinese Operators Hope to Standardize a Segmented Internet Posted on Monday Jun 18, 2012 10:20 AM by Mikael Rickn=E4s A technology draft written by employees at China Mobile and China Telecom and submitted to the Internet Engineering Task Force describes how the Internet could be split into several parts using the Domain Name System and in the process give countries more control over their own segment of the network. The DNS is one of the key building blocks of the Internet. Its most important task is translating IP (Internet Protocol) addresses to host names, which is done by a distributed system based on one unique root that is used all over the world. The technology is developed by the IETF, on whose website the Chinese "DNS Extension for Autonomous Internet" draft is available for viewing. Today, China blocks Internet access to some foreign websites. The goal outlined by the new document is to make it easier and cheaper for countries to create independent root DNS servers and realize Internet autonomy. Today, that is both costly and technically difficult, according to the draft. "When you read the document it very much comes across as a way to severely segment the Internet," said Patrik Wallstr=F6m, CEO at OpenDNSSEC AB, a not-for-profit company with the mission to facilitate the deployment of DNSSEC, which is used to secure DNS. If the draft is adopted it would give, for example, China full control of content on the Internet for users in the country as well as how it can be accessed and by whom, Wallstr=F6m said. The reason for adopting the draft into a standard architecture would not be just for control, according to the authors. The current central architecture of DNS can't keep up with the fast development of Internet, they say. That argument doesn't ring true, according to Jakob Schlyter, a DNS expert at Swedish consultancy Kirei. "When you say something like that you have to back it up with some facts, which I don't think they have ... the DNS root has an extreme overcapacity," said Schlyter. However, the chances of the draft being adopted is very remote, according to both Wallstr=F6m and Schlyter. Anyone can individually submit an Internet draft to the IETF. But since the intended goal with the Chinese document is standardization, it first has to be picked up by one of the IETF's working groups, and that isn't going to happen, Wallstr=F6m said. "It is a controversial subject, and the IETF works on standards that, in principle, are for the global Internet," said Wallstr=F6m. The idea of moving away from a central DNS root also goes against the IAB's (Internet Architecture Board's) technical comment from 2000, detailing the need for a unique DNS root to ensure the future of the Internet, according to Wallstr=F6m. The comment came after several alternative roots came into existence during the nineties, he said. "The Chinese draft would be a return to that," said Wallstr=F6m. Schlyter is equally convinced that nothing will become of the draft. "There is an extremely small risk of it going anywhere. I say risk because I am proponent of a common namespace, and all that comes with that," said Schlyter. Because of the minuscule chance of the draft ever becoming a standard, the underlying reason for publishing it may be something altogether different, according to Wallstr=F6m. "This is just me speculating, but with the arrival new generic top-level domains (gTLDs) a document like this one can be published to put more pressure on ICANN with the aim of maybe even splitting the organization into different parts where China has more power," Wallstr=F6m said. Today, ICANN (Internet Corporation for Assigned Names and Numbers), which is also a big proponent of a unique root, coordinates the DNS as well as a whole host of other Internet-related components. These were originally performed under a U.S. government contract. Send news tips and comments to mikael_ricknas@idg.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 25 06:54:58 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1C21F8604; Mon, 25 Jun 2012 06:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340632498; bh=BpCP4ASOrBZj5zTI9AdqtyLhh74FgqQW6cRJk0cS950=; h=Message-ID:Date:From:To:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=bsFpAgzuWuPDtaVNlf42vV+pVTN6cI7B6DhlQlYmTF49JstUDkUXb0rLMxXWPCreL WpBNzOZFdXkbVYV2rFwb5pmFi6z6RZO0NJK59qRc2nrKTirr4VZ3zV+USml1egWblB ThzymsjWozN/hSZCZJ29Ge3oXP5puoNH9etcUg6c= 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 A4ACF21F854B for ; Fri, 22 Jun 2012 23:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.138 X-Spam-Level: X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, J_CHICKENPOX_53=0.6] 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 MXC7Pw3x0Xl5 for ; Fri, 22 Jun 2012 23:35:14 -0700 (PDT) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with SMTP id 77EE621F8548 for ; Fri, 22 Jun 2012 23:35:14 -0700 (PDT) Received: from [98.139.212.152] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jun 2012 06:35:13 -0000 Received: from [98.139.212.230] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jun 2012 06:35:13 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 23 Jun 2012 06:35:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 863710.10179.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 48212 invoked by uid 60001); 23 Jun 2012 06:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1340433313; bh=/vbtHR8p7SfOofTg7Q/ZFq244lwhrYcixXONgzbJC6A=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WDahvphUiGRxdtFIzhGsAnGHj6AArhM3VRGGljRf45EdP6MQuLlJdjSsT9A+dCvvyAKEPaMS5L2UhBigYEs6m4u9074n3pkLbJjgOQa/9LFYl9oMhah0QtwF1MbfaQXPvjscUP/sc/uQD17NuW+Y2+dvxt1ylvs42UBT65DGK2Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wHyZSMCfVeJWLQreK7jB86NBstvQwMfzh1MJIySEwiERxG1w8DTdfqpTgtOf5Wung9InTo+1lkXCpiXvnDV1NuCNZoD1z5KbdsQm761hYMuv53YWHiBuhzweUbhQG3WRfkGNa68zBtBg6zWOZ7Pe6K4cBZqNmsJOMPn3oZGqnKE=; X-YMail-OSG: tmgEv38VM1kw2ZsCIqWa2AT1I3ZUkxyYdtFez2BWB_FWgac WtgQnIjjs Received: from [113.111.200.196] by web161701.mail.bf1.yahoo.com via HTTP; Fri, 22 Jun 2012 23:35:13 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> Date: Fri, 22 Jun 2012 23:35:13 -0700 (PDT) From: YP Diao To: draft-diao-aip-dns@tools.ietf.org, Fred Baker MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Jun 2012 06:54:58 -0700 Cc: namedroppers@ietf.org, itu2012@elists.isoc.org, dnsext@ietf.org 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --- On Mon, 6/18/12, Fred Baker wrote: > From: Fred Baker > Subject: draft-diao-aip-dns > To: draft-diao-aip-dns@tools.ietf.org > Cc: namedroppers@ietf.org, itu2012@elists.isoc.org > Date: Monday, June 18, 2012, 1:31 PM > 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? I have not information about the BRICI proposal in WCIT and this is not rel= ated to it. > 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. This would not affect Internet communications in traditional ways. Based on= Internet practice, autonomous internet (AIP) techinology can transform the= Internet into Autonomous Internet (AIP) without protocol change, using mod= e change, transition period. It would be more reasonable and efficient that internal domain name resolut= ion is no longer via the DNS outside this AIP network. As described by AIP DNS rule 2 in Section 2.2, different AIP network defaul= t domain name suffix needs to be assigned by IANA. > = > = > Comments on the paper itself: > = > The Introduction opens with the sentence > = > =A0=A0=A0Internet Domain Name System (DNS) > distributes domain name and IP=A0 =A0 =A0 = > =A0=A0=A0address for the host on the Internet. DNS > automatically translates=A0 =A0 = > =A0=A0=A0the domain name into IP address when user > accesses Internet using=A0 =A0=A0=A0 > =A0=A0=A0domain name. = > = > 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. > = Strictly, I admit! > 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. This recursive translation would happen only in local DNS server and AIP DN= S GW but not AIP DNS roots. > = > One general comment on sentence structure: in English, it is > considered poor form to start a sentence with "And". For > example > = > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0=A0=A0And any IP node's external domain=A0 > =A0=A0=A0 > =A0=A0=A0name is consist of its internal domain > name and its AIP network=A0 =A0 =A0=A0=A0 > =A0=A0=A0default domain name suffix.=A0 =A0 = > = > should read > = > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0=A0=A0Any IP node's external domain=A0 > =A0=A0=A0 > =A0=A0=A0name consists of its internal domain name > and its AIP network=A0 =A0 =A0=A0=A0 > =A0=A0=A0default domain name suffix. = > = > While the specific point is a nit, I see it frequently in > the paper. Thank you for detail revision! It would be helpful for its next version. > = > 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. AIP just provides more flexiblility and possibility to international busine= ss and communications. For Google or Baidu, they can apply different local = URL for different country to provide differentiate services as usual(for ex= ample www.google.cn, www.google.com.hk...); or they can apply a unified URL= for all countries such as www.google.com and just provide a link for diffe= rent countries. = In AIP,=A0 The another additional possibility is to apply identical local U= RL for different country to provide differentiate services.=A0 = > = > = > 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... > = I didn't have chance to disscuss this with Professor Qian Hua-lin yet. But = I agree throughly that new technologies should provide more flexiblility an= d possibility for people equally but not limit the free and equal internati= onal communication right-it is the soul of Internet forever! > 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? > = AIP technology is so simple as it describe in this draft. The prospect of f= uture Internet would be more open and scalable if we can just imagine openl= y! = > sincerely Diao Yongping _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Jun 25 06:55:28 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CAA21F8647; Mon, 25 Jun 2012 06:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340632528; bh=6omrI+raL64gmYarNfnbrZNHgFL1Ko/UY3ZQRBd+ops=; h=Message-Id:Date:To:From:In-Reply-To:References:Mime-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=LJp8+nFb6njB90pEOBLAd4iYD/UsdNlMPKCBcLICCCLWtkYP2stjEorbHLcHARZvx nuRXYh4L+xl9mo9ltKj4ubu9oc3PdcjDyx55P3746nopjRF3kG9uK29muaxvT1D0qa TrC9ixyebbLKUcPf1miBYqfMY3V76F61FA+Xdrgs= 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 CE82721F8694; Thu, 21 Jun 2012 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 bBzZANe+ZppU; Thu, 21 Jun 2012 13:32:54 -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 67CBA21F8659; Thu, 21 Jun 2012 13:32:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5LKWYpZ018614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 13:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340310769; i=@elandsys.com; bh=M5CZ2NMNE8oAvkY8GrOi+UV04MIrYZVlk5HB5Fw2YYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NwkzE2NiCfjMu7idBbGS52Zq5PkcwvE9FwDS3MobQXE7RtiScyNKWr6lIqbFOaIby 3gTFSuSj4GnOqdsjK/iXqRocY5JnjCKosiJX8B4mXbDvvWiw6g3w4bUS7YbINsB5h5 2quPRdp3IeKk3jZw2eueuWgdy7ajL9Bux7f4KLQE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340310769; i=@elandsys.com; bh=M5CZ2NMNE8oAvkY8GrOi+UV04MIrYZVlk5HB5Fw2YYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UIoIwlajYDZl5KgCEwgcSKrRBdEg1Q4kdW9RZLve38rnaFJV8GRF45I6yGYd2Sfcw AkrvK2yRGHvUppIZQqxy65UQkxGCgkG3lg2pBuIDGJUgYyJrSOm475vLQsYoLgBLeU MVKkYJl9xaEJSJvXYAVo6RriQYhl4GAHVPZvGQd0= Message-Id: <6.2.5.6.2.20120621110715.0a33ef38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Jun 2012 13:31:33 -0700 To: Andrew Sullivan From: S Moonesamy In-Reply-To: <20120619023034.GJ32683@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> Mime-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Jun 2012 06:55:27 -0700 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi Andrew, At 19:30 18-06-2012, Andrew Sullivan wrote: >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? I mentioned "implementers who are fully conversant with the ins and outs of DNSSEC". There are people implementing code using DNSSEC signing and/or validation who are will be using the DNSSEC document set. The text in the draft does not mention that it is aimed at, for example, BIND, Unbound and Powerdns implementers only. In the review posted at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05954.html I mentioned three parts of the draft which did not seem clear to me. I'll comment more on this below. >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. Jiankang Yao commented on this in a message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06315.html The other part of the comment was "raises questions about whether the DNSSECbis documents will ever be advanced in the near future from Proposed Standard to Internet Standard". >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. Ok. >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? The above explanation is clear. The first paragraph of Section 2.1 is clear. This draft updates RFC 5155. When I performed the review I compared the requirements in the last paragraph of Section 2.1 with what's in RFC 5155 to find out whether there is a change in the requirements. >There aren't any, but we can't practically require it because under >memory constraints a cache is going to be emptied anyway. Ok. >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. Agreed. >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? I found your answer to Richard Barnes' comments clear. I'll quote it: "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." Quoting from Section 4.1 of the draft: "[RFC4035] Section 5.4 under-specifies the algorithm for checking non- existence proofs. 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." I'll suggest text and leave it to the editor to see what's better: In [RFC4035] Section 5.4, an attacker could use an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence of RRs in the child zone. An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: o the NS bit set, o the SOA bit clear, and o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. The algorithm in [RFC4035] Section 5.4 is updated as follows: Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume ... As a matter of style I would replace Section 5.4 altogether so that it is clear to the reader. >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? I generally go through all the normative references before reading a draft. I also refer to the original (opened) document when reading. Although I don't think that it will be done, I would suggest updating the actual RFCs instead of publishing a set of clarifications. I'll keep to the publication recommendation I made previously. I suggest not to pay too much attention to that. I cannot give the draft a pass. The IESG can do that and nobody will be unhappy. :-) Regards, S. Moonesamy _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 26 16:52:43 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3122D11E80EB; Tue, 26 Jun 2012 16:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340754763; bh=ht9lMhAUVGoVf7RuioXnyZcjrExoB/BW1NHyqHRZbZc=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=HIhitLaJvY1uzYsKClTyTsHAFmpFt/IpuoYx7OG/7v3OiN3I1MYDQBgp5oTHRvB6Q hWyipdDqKu+QmVVLqe103Wnmr+LV42UrN6BNZ6NkGG+UUXG8xBKZ7So8oHdfs5xaEi jozNI2Da5+F7vboYZ9+9Y2pqGQItBGMgI4RrT2Js= 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 1FC4C11E80EB for ; Tue, 26 Jun 2012 16:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 kPSuKCljhscU for ; Tue, 26 Jun 2012 16:52:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9015111E809F for ; Tue, 26 Jun 2012 16:52:40 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5QNqacf054986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Jun 2012 16:52:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> Date: Tue, 26 Jun 2012 16:52:36 -0700 Message-Id: References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1278) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Sorry to keep this thread alive *and* ignite the IPR bun fights at the same time, but: . --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 26 16:56:38 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82811E80E8; Tue, 26 Jun 2012 16:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340754998; bh=uGlUjHmlbmkdCLUO0k5bR77j8eYenGPFKz8asNGslOQ=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Z53qv6aGeD6YRm4t1UHOorMCTCN5AdE/ETo3tv5cWFyA0MPDuIQRWt7vBUHsXL3PQ S29L9mF6zA5qz4BBC24sd0tQD4fvFAGsRjxckG1YkDjr8QEJmgRc+Dxo8Tiq3UJTQ9 ObYNa0HtnxE69eKBhkVqLtwve+umAlAxvtyWTRSE= 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 BC38911E80E8 for ; Tue, 26 Jun 2012 16:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 7hA8-Qz6jgwx for ; Tue, 26 Jun 2012 16:56:35 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id A5BB311E80AE for ; Tue, 26 Jun 2012 16:56:35 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 7FDD14CEE82; Wed, 27 Jun 2012 01:56:32 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id LhpeTWk0Xfcr; Wed, 27 Jun 2012 01:56:31 +0200 (CEST) Received: from macbook.bluepipe.net (unknown [207.98.72.184]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id 33D654CEE6D; Wed, 27 Jun 2012 01:56:30 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id 240D5B8A3CA; Tue, 26 Jun 2012 16:56:28 -0700 (PDT) Date: Tue, 26 Jun 2012 16:56:28 -0700 From: Phil Regnauld To: Paul Hoffman Message-ID: <20120626235628.GE99568@macbook.bluepipe.net> References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Darwin 11.4.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: DNSEXT Working Group 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Paul Hoffman (paul.hoffman) writes: > Sorry to keep this thread alive *and* ignite the IPR bun fights at the same time, but: . > >From http://www.patentics.com/html/20419/9104.htm (through Google translate): The present invention to achieve autonomy Internet security scalable, and the Internet autonomous transformation, the transition is smooth and feasible; can break the monopoly control over the Internet, has its own root name servers to effectively safeguard national Internet security; for the modernization of national defense, economic and other, are very important. ? _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Jun 26 17:11:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1026B11E80BC; Tue, 26 Jun 2012 17:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340755876; bh=ZOB/pYZCr9LAt1qew86F7mMlbrZfE6vgTvgGume0vYw=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=gbxy1E+XFa4k7cTJ/hYZJSizgZRYX/g1I/y4EYTdDI/hFRQIgwps8ro995ZyAkSs3 vMYsK0nT9zUxZxp6VCdwzYfr3btkBHvTobzppr5Ayggsomn3pWndWX0CgChE/3XNrg ySFNDLT3Qks5r5Xkyem+8noLQHy8hkNnEwJmDrcg= 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 71E2211E80BC for ; Tue, 26 Jun 2012 17:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 O8jL79fVQ5lr for ; Tue, 26 Jun 2012 17:11:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A7CE411E808D for ; Tue, 26 Jun 2012 17:11:14 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5R0BDvn056683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Jun 2012 17:11:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <20120626235628.GE99568@macbook.bluepipe.net> Date: Tue, 26 Jun 2012 17:11:12 -0700 Message-Id: <779C61FF-43C5-4FDE-839C-21D6B62FC6F7@vpnc.org> References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> <20120626235628.GE99568@macbook.bluepipe.net> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1278) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Jun 26, 2012, at 4:56 PM, Phil Regnauld wrote: > Paul Hoffman (paul.hoffman) writes: >> Sorry to keep this thread alive *and* ignite the IPR bun fights at the same time, but: . >> > >> From http://www.patentics.com/html/20419/9104.htm (through Google translate): > > The present invention to achieve autonomy Internet security scalable, > and the Internet autonomous transformation, the transition is smooth > and feasible; can break the monopoly control over the Internet, has > its own root name servers to effectively safeguard national Internet > security; for the modernization of national defense, economic and > other, are very important. ? Note on IPR bun fights: quoting bits of a patents, particularly the abstract and not the claims, generally does not aid the IETF process unless the topic is one which there is agreement that there should be a standards-track protocol. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Jun 27 06:52:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEBD21F863E; Wed, 27 Jun 2012 06:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340805123; bh=m1QCQQgTGKM4HqjdejS1c1s6n+/YACmRlrmlTvvy2PM=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=sWVpqO4dfuRG1B8s3FQdfvbk0RGWdldogmMEeFK/RPQoCjEc829ei4WjVyoa0WOe8 6mEoTnUiiceHMfrrKNLCqwCwzacgCi/X9FHm2eLuVgDD5r1oAAYzZzirEVRJxt7ZJQ W1QuBk3vudiGs+QUGFoGjdgSxOzAlWTkTY9Jvpk4= 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 106A121F863E; Wed, 27 Jun 2012 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 671ZNoBRDeFk; Wed, 27 Jun 2012 06:52:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBE621F85A4; Wed, 27 Jun 2012 06:52:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627135200.7350.6275.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 06:52:00 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status) to Best Current Practice X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 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. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. Note that this document responds to the objections raised against draft-ietf-dnsext-dnssec-registry-fixes-08; the earlier document was split into this document and draft-ietf-dnsext-dnssec-registry-update. The implementation status information published in this document was originally published in draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and controversial use of the IANA registry. That approach was too controversial, so this document publishes that information separately. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Jun 27 06:53:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC95521F875D; Wed, 27 Jun 2012 06:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340805187; bh=d5Zt7AcpiE5u7OBpsiu6TWdAHp/vqHjcYEr9hJr7zuE=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=POffyDAgA6b3Qv5znVyQXBIsiQwgnHs05UXEP+X3AhS18NIkTmlW+Wi0gnKgzCkLm TEZN14OfmdlxPsCGIGlZ2PirPCuATgKToDl7L0T52JvC6N+LzMBsirqbqUfRk+YyZK fdp0L9eVcnFNczd2ReZeGpZfxLruWKSsov3SyIWI= 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 D89B221F8754; Wed, 27 Jun 2012 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 9TZNF-VUgTO1; Wed, 27 Jun 2012 06:52:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4F21F8757; Wed, 27 Jun 2012 06:52:57 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627135256.11457.74759.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 06:52:56 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. Note that this document responds to the objections raised against draft-ietf-dnsext-dnssec-registry-fixes-08; the earlier document was split into this document and draft-ietf-dnsext-dnssec-algo-imp-status. This document specifies the changes to the registry that were considered non-controversial during the review of draft-ietf-dnsext-dnssec-registry-fixes-08. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 28 13:43:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7135A11E80A2; Thu, 28 Jun 2012 13:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340916192; bh=Z9hEmUGuLerUrGiLOv41hnOEzyRuguex/RUBEM+xxYg=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RuLrMMbcudogXocKmtuAvJS3oYKs69MaapU8Jl7xESIWOJDBnFr6zteZPqwgqy3EG DbA5QY/cjkMnUc8k6s6ge7fA/CWZbogE7AKnZYodXxQf5bQ3AA1ysiugzx0RceN7Hb FYJu75yd0q8skJBMorWqoOoVtTMB1u2ild2S/FFY= 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 27E9611E80A2 for ; Thu, 28 Jun 2012 13:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.312 X-Spam-Level: X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 x14--SdpT8Mb for ; Thu, 28 Jun 2012 13:43:10 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BA11E809C for ; Thu, 28 Jun 2012 13:43:10 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 6E8593B3CD; Thu, 28 Jun 2012 20:43:08 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id BC7E5C952A; Thu, 28 Jun 2012 22:40:21 +0200 (CEST) Date: Thu, 28 Jun 2012 22:40:21 +0200 From: Stephane Bortzmeyer To: dnsext@ietf.org Message-ID: <20120628204021.GA19864@sources.org> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 6.0.5 User-Agent: Mutt/1.5.20 (2009-06-14) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Wed, Jun 13, 2012 at 10:00:50PM +0000, Roy Arends wrote a message of 107 lines which said: > If you have comments regarding this request please post them here > before July 5th 18:00 UTC. No comment, just to say that I've read the draft (and the other ILNP documents) and I agree that these new records are a good idea and well described in the draft. (Except that the bug found by Tony Finch about the LP record must be addressed.) _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 28 13:48:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C746211E808D; Thu, 28 Jun 2012 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340916495; bh=H6KsZbw9FiXuNz7uO4Ia9zBO2EOQwN9CV83ywdxSNi0=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=oWbjo5B324tsjjbOl7j1Im6daHPDJJFexej6PoEoycQz4UgbXnutNg36Q2i4xeN6z rUO00O9QC8tw/DXUhrehqKiJDaoU/VnHxXIiNjmKWHTCr8uWs5qbSTUSvGbZR8Z37y 6o8aLMvRMHE6rFXy4yKhTnWp24+FXX6mCea0I0SY= 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 272FF11E80C1 for ; Thu, 28 Jun 2012 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.056 X-Spam-Level: X-Spam-Status: No, score=-101.056 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 loV3wKyjEWI9 for ; Thu, 28 Jun 2012 13:48:12 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 5405011E808A for ; Thu, 28 Jun 2012 13:48:11 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 29BEA3B3DC; Thu, 28 Jun 2012 20:48:09 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id DAF87C952A; Thu, 28 Jun 2012 22:44:59 +0200 (CEST) Date: Thu, 28 Jun 2012 22:44:59 +0200 From: Stephane Bortzmeyer To: Tony Finch Message-ID: <20120628204459.GA20824@sources.org> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 6.0.5 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: RJ Atkinson , SN Bhatti , "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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Thu, Jun 14, 2012 at 07:09:11PM +0100, Tony Finch wrote a message of 36 lines which said: > 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. I suspect that this may be because ILNP strongly discourages the use of either NID or L64 outside of the DNS context. There is no way to use the NID or the L64 alone to contact a host ("telnet NID" does *not* work.) When you use them, it is as an IP address ("telnet L64:NID" is discouraged and will not use ILNP to connect) so general IP address rules will apply. Remember that ILNP strongly relies on the DNS, much more than others Locator-Identifier Separation proposals. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 28 14:36:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2F21F858D; Thu, 28 Jun 2012 14:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340919368; bh=O3SkCoFLCOzXrWfKBcSBJdBiDjtGwjjdQiasRnPIccQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Ai0XZRy0r5UjUyl9lkpzedIOooZv7FQr/jqMy6cjBkipoizzAf7DzLDZe/bERLk/q WOzqNKO/M5G+O70gUDjzRKfQDoVZUWuopvXutE/Cc87rhH6ntZ2r0nnP2K13rmQbhO Ap28nTmjNPTGZuXqlywBc2IiOI5Td+DKvK3S+VRQ= 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 2A3D521F86B8 for ; Wed, 27 Jun 2012 10:23:59 -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 RqJZ5nu+ve+x for ; Wed, 27 Jun 2012 10:23:58 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id A66B221F86A1 for ; Wed, 27 Jun 2012 10:23:58 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7E0C0A1051 for ; Wed, 27 Jun 2012 17:23:57 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:914f:79c1:78cc:73c8] (unknown [IPv6:2001:4f8:3:30:914f:79c1:78cc:73c8]) by nsa.vix.com (Postfix) with ESMTP id 59CCBA101E for ; Wed, 27 Jun 2012 17:23:57 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4FEB41AB.1020804@redbarn.org> Date: Wed, 27 Jun 2012 17:23:55 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.4.2 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 28 Jun 2012 14:36:07 -0700 Subject: [dnsext] fun patent on dns-0x20 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org olafur pointed me to which describes dns-0x20 and was filed june 1, 2011. this is fun, since the dns-0x20 draft was done three years earlier, and implemented in unbound at least two years earlier. anybody from "CHENGDU HUAWEI SYMANTEC TECHNOLOGIES CO., LTD." want to comment? paul _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Jun 28 19:16:34 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10CB11E8113; Thu, 28 Jun 2012 19:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340936194; bh=djkJ+vS4FJazTOEhUCnnd77FnUFe6Vddk/I4rXG4C2U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=R8ZTQtKX0M2wvLGKJ/8fgAkk2RAjGoxrvgcsIO2HUoPhSzODW2FslcmMFdp8bWx30 UX+iCOwSNe1Dc+niy4PQ53jVt6Ttu/D4Vxtl/DwaOGtiFyqvAu5lCYDkbXCTWEs+pc OugMwtZ2/PPzU2b1x57iQsTyIi/+LPP7iZR26btE= 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 5022411E8113 for ; Thu, 28 Jun 2012 19:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, 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 oztoJJK+zGg5 for ; Thu, 28 Jun 2012 19:16:32 -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 3640011E80FA for ; Thu, 28 Jun 2012 19:16:32 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2643726ghb.31 for ; Thu, 28 Jun 2012 19:16:31 -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=TRfn048hZOB1aCaKRFcfxDIFeilG4gjO74QV/LY0FSc=; b=E+6fP7pd8g36rY+ZfaLjiimkxMEY54bPQB+ky+CArA4ZrpbTnsKWM+yDN8eCGONmAP eb4UL73QSG/LKIv2A6qVjmkX+NpoMdr6/WsPMjBGLVY1ju2+a/Z36gcObBQgF0lwhul/ PxwgCiexMoaxhgBAhDM8ZbCGuODb2oUXAKLTuWr9+yByID58UNTe7o7CDtsxqqXTTWHI V7DQyTCkY3VSeqLftlAJF+cW/dk9g8W+HJx44meKjaEX6lOS7VP1KctnKvdbgCy29cGq vKIHVXdzsi1WiwY3R3GCctWswtZptSmneasfzmv4mjCK91uc2vZzLsR8+Fm7Ki+QDuRv TJJg== Received: by 10.50.213.106 with SMTP id nr10mr243208igc.58.1340936191250; Thu, 28 Jun 2012 19:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Thu, 28 Jun 2012 19:16:10 -0700 (PDT) In-Reply-To: <201206141304.PAA00956@TR-Sys.de> References: <201206141304.PAA00956@TR-Sys.de> From: Donald Eastlake Date: Thu, 28 Jun 2012 22:16:10 -0400 Message-ID: To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Cc: dnsext@ietf.org, ogud@ogud.com 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi Alfred, On Thu, Jun 14, 2012 at 9:04 AM, Alfred H=CEnes wrote: > ... > > (1) =A0Section 3.1.4 and/or Appendix B > > Maybe the IESG will call for a citation for closing the AFSDB > sub-registry. =A0RFC 5864 is the proper reference (and its author has > approved the formal closing after checking with the AFS community). Adding such a reference seems reasonable. I suggest that, just before the last sentence of the first paragraph in Section 3.1.4, adding "Use of the AFSDB RR to locate AFS cell database servers was deprecated by [RFC5864]." and noting this addition in Appendix B. > (2) =A0Section 3.2 > > In the RCODE registry (Section 2.3), there is an apparent > overloading of RCODE=3D16: > =A0 BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845). Yes. But it seems unlikely to cause a problem as one is only used in OPT and one s only used in TSIG. > Looking back into RFC 2845, it seems that the clerical error > has happened at IANA when acting upon the assignments in that RFC. > The second paragraph of Section 7 of RFC 2845 (on top of page 13) > clearly states: > > ! =A0IANA is expected to create and maintain a registry of "TSIG Error > ! =A0values" to be used for "Error" values as defined in section 2.3. > ! =A0Initial values should be those defined in section 1.7. =A0New TSIG > ! =A0error codes for the TSIG error field are assigned using the IETF > ! =A0Consensus policy defined in RFC 2434. > > Note that the TSIG Error field is a component of TSIG RDATA distinct > from the RCODE field in the DNS message header and its extension in > OPT RRs. =A0An According to RFC 2845 (which seems to be mostly unaware > of EDNS, besides references to binary labels), there is an intentional > semantical overlap for Error values 0..15, which are specified as being > identical with the non-extended RCODES (0..15) in sect. 1.7 of RFC 2845; > the "new" TSIG Error values 16..18 are to be signaled together with > RCODE =3D NotAuth(9) (originally specified in RFC 2136). > The idea there obviously was to make TSIG independent of the OPT RR, > i.e. to allow TSIG without EDNS, but to this end RFC 2845 likely better > had accomodated the extended RCODE BADVERS(16) assigned by RFC 2671 and > chosen Error values 17..19 for TSIG purposes. Of course, your quote from the IANA Considerations of RFC 2845 (TSG) is correct; however, I do not think the evidence is all on your side. In particular, earlier in RFC 2845, the error field is described as an "expanded RCODE". This is essentially the same term that RFC 2671 (OPT) uses ("an extended RCODE") and the same term that RFC 2930 (TKEY) uses ("The error code field is an extended RCODE."). > However, IANA obviously has registered the actual new values 16..18 > in the RCODE registry and _not_ established a TSIG Error code registry. > Mistakes happen, and it also may be wise to have RCODE values 17 and 18 > "reserved" so that additional overloading cannot arise in the future. > > But IMO it would be worth adding "[*]" to the three RCODE registry > entries based on RFC 2845: BADSIG, BADKEY, and BADTIME, e.g.: > > =A0 =A0 =A0 =A016 =A0 =A0BADSIG =A0 =A0TSIG Signature Failure [*] =A0 =A0= =A0 =A0 [RFC2845] > =A0 =A0 =A0 =A017 =A0 =A0BADKEY =A0 =A0Key not recognized [*] =A0 =A0 =A0= =A0 =A0 =A0 [RFC2845] > =A0 =A0 =A0 =A018 =A0 =A0BADTIME =A0 Signature out of time window [*] =A0= [RFC2845] > > ... and to add a footnote to the rigistry that says (e.g.): > > =A0 [*] These values are only to be used in the Error field of TSIG RRs; > =A0 =A0 =A0 they cannot appear in the (extended) RCODE field of OPT RRs. > > Also, for added precision and consistency with RFC 2845 and RFC 2930, > the last clause in the first paragraph of Section 2.3 should perhaps > be adjusted as follows: > > OLD: > =A0 and the TSIG and TKEY RRs have a 16-bit RCODE field. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 ^^^^^ > NEW: > =A0 and the TSIG and TKEY RRs have a 16-bit Error field. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 ^^^^^ I believe that the more different DNS error registries there are, the more confusion and the more future errors in assignment will occur. Except for the values of the 4-bit DNS header un-extended RCODE, for which precious few free values exist, there is an abundance of values available, so there is no scarcity reason for separate registries with potentially overlapping values. It is also the case that a single unified number space for DNS errors has been presented for years in RFC 6195, RFC 5395, and RFC 2929 for use in the unextended DNS header, the OPT extended DNS header, the TSIG RR error field, and the TKEY error field. In all these years, no one has had a problem with there being a single, unified DNS error number space. So, to the extent that there is any consensus among these document I believe it is for the simpler model of a single number space. To the extent that there s any ambiguity here, I would prefer to resolve it by adding text to Section 2.3 of the rfc6195bis draft like the following: "To the extent that any prior RFCs imply any sort of different error number space for the OPT, TSIG, or TKEY RRs, they are superseded by this unified DNS error number space. With the existing exception of error number 16, the same error number MUST NOT be assigned for different errors even if they would occur in different RR types." 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 > Kind regards, > =A0Alfred. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys= . =A0| > | Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0= =A0 =A0 | > | D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > +------------------------+--------------------------------------------+ > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 05:43:32 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB4F21F8659; Fri, 29 Jun 2012 05:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340973811; bh=4t6Pz4/QnNbWoNKxvmN3MRmXUYtP9LYXjPMyfsQvdss=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=XEQWOWluh7z3760KZx+9TfaPwDqGCZ55de4K9cyTvF3aPTWgz9V2RuEMCPPst+Zzl OrzwEEdQNotoksxorQDw1oLqu5lUoL6y6RRwTL/EQi2RizqQSpRjFE/Yd/HL00wJVJ HSOV6S+r5ctkkaKNQLU14zNMGC0qNmtGDoS+31Jo= 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 D0D6621F8653 for ; Fri, 29 Jun 2012 05:43:29 -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 AHzod0IuQxf4 for ; Fri, 29 Jun 2012 05:43:28 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3144B21F86D1 for ; Fri, 29 Jun 2012 05:43:28 -0700 (PDT) Received: by yhfq11 with SMTP id q11so3225108yhf.15 for ; Fri, 29 Jun 2012 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kyzGF6tfzx0X07oekek+IMg6mUOJnmXNWkCe3QTswW0=; b=isQ4HTLP3H3TShCJYXmNGDFvGCIPrprpAzp3/df4EgVw+KnvJHQ0S9JfL1e9xWeb71 XZvJBl8dXTxKgjO2F+3hbEGm+1hFIp7ZwpWbR1/WGRhijhryUkg1FPuXpcQBvbKhH04G 4ffkZiGNpiV/e3m6c8VuZVVl+pTzJAc0eS0YU2z7B5BDOgvQOwAeiyOzVncKDTrTkj8h 1q/SwbrYjrtvOyxHL8dk8sStou9hGD1cWeyj+UqQQAjLXJiCWeFVEhSI7xP3vXP/7J63 WBOfpVw6/djURZQHvTncbgZ3gJjPvb507XHvFv7tjeQBodPRsa2NTrQOXFLBq0qd4tNW X4JQ== MIME-Version: 1.0 Received: by 10.236.176.129 with SMTP id b1mr2220191yhm.126.1340973807686; Fri, 29 Jun 2012 05:43:27 -0700 (PDT) Received: by 10.147.33.19 with HTTP; Fri, 29 Jun 2012 05:43:27 -0700 (PDT) In-Reply-To: <4FEB41AB.1020804@redbarn.org> References: <4FEB41AB.1020804@redbarn.org> Date: Fri, 29 Jun 2012 08:43:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Vixie Cc: dnsext@ietf.org Subject: Re: [dnsext] fun patent on dns-0x20 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Looks like someone needs to send a notice of prior art to the alleged inventor. When the USPTO started publishing applications there was a statement that the PTO would not accept any prior art submissions from third parties. The objective appearing to be to avoid the US system becoming like the rest of the world where public objections play a major role in weeding out the rubbish. It seems to me that this might make a good point to challenge the PTO on if people were willing to do it. The PTO might have a policy but agency policies are subject to judicial review. It is also quite possible that the policy has changed since the Bush administration. The idea that an agency can intentionally cut itself off from advice from the public when making a decision to grant a monopoly that might impact their business is rather strange. The patent lawyers usually argue against this sort of thing as courts are less likely to accept prior art that has been reviewed by the PTO. But that assumes that the PTO does not reject the patent. On Wed, Jun 27, 2012 at 1:23 PM, Paul Vixie wrote: > olafur pointed me to which > describes dns-0x20 and was filed june 1, 2011. > > this is fun, since the dns-0x20 draft was done three years earlier, and > implemented in unbound at least two years earlier. > > anybody from "CHENGDU HUAWEI SYMANTEC TECHNOLOGIES CO., LTD." want to > comment? > > paul > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Website: http://hallambaker.com/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 07:31:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A3521F8738; Fri, 29 Jun 2012 07:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340980290; bh=tx5pWd8m+03f21yVf3vZqxYSHrweeNOm5wnJEGwhV/E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=GxYcC3wwSIuRgTbxavYyt7deJ/TuCjPYTkbEtq7fOa0H9Ib6Yx4rXd0koCBwZm5WS mQtlDkBQcKNulkDcdzZT8Hw2m3pY4vTDRLeDz1pX0shv0Yp+tQ8h8WK55nEOUYrjtq R2K8D4rpiSVP0DEC28Ow3Wec2Qoz4reNwvn0nvMA= 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 C71A321F8741 for ; Fri, 29 Jun 2012 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_05=-1.11, MISSING_HEADERS=1.292, 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 cYdVCWf-7-ZW for ; Fri, 29 Jun 2012 07:31:26 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6C421F8757 for ; Fri, 29 Jun 2012 07:31:22 -0700 (PDT) Received: by yhfq11 with SMTP id q11so3361478yhf.15 for ; Fri, 29 Jun 2012 07:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=dvBoknl8/bNDep7jsOuDJ14rGGDl7HE/OgQ6TphJC4Q=; b=ExHMq4Y1ASsDl1kG7rtYXXwjWwjEavVy6IT4pyaJjuTdhyudhB94czAGHTGmps4tFN Dvzk7iyKkperU9IiHujZ7NIKSM2h/+pk4sAH9vNyi8cvygBg7IUWKac5DOSZymanZjjL HB0TCe2UESLeLZJTQjGBx0h8cPDyNckmm+JIbq8yb16mQ2ij6jNNBcmRO9xaAlCJOdfy 8V/n+4k//KxrVA4iUmreYGATjiXiUP4XPTSHPIPWPWZGLFdIeYXPvLfe8XuiF9aZMtl4 SzPJrmcJThoTvpXL0MbVpUcTUYNFsaMNW09M+F2jBwvw9JKrSpjflUjoKsH4kdaKvUPp n8uQ== MIME-Version: 1.0 Received: by 10.236.76.9 with SMTP id a9mr2931206yhe.96.1340980281990; Fri, 29 Jun 2012 07:31:21 -0700 (PDT) Received: by 10.147.33.19 with HTTP; Fri, 29 Jun 2012 07:31:21 -0700 (PDT) In-Reply-To: References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> Date: Fri, 29 Jun 2012 10:31:21 -0400 Message-ID: From: Phillip Hallam-Baker Cc: DNSEXT Working Group 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Those of us who have been watching the moves by Russia and China for some time, in particular their proposals into the Dubai ITU meeting have been expecting something of the sort for some time. The draft in question is simply describing a capability that the Chinese have had deployed for at least five years, albeit maybe in a different technical form. People have been proposing splitting from ICANN since before there was an ICANN. And when the CEO is being paid close to a million dollars a year and the whole operation is being driven by rent seeking, I think many of the people behind those proposals might be seen as prescient, if not for the fact that many of them were looking to achieve a bit of rent seeking of their own. CABForum is currently looking at the bad things that could happen if .corp is allowed. It turns out that a large number of corporations already use this internally. Now leaving aside the technical considerations, I do not think that CABForum should have to pay $17,000 to make a formal objection on security grounds. Of course Russia and China are going to find plenty of other countries to support their position when the status quo is indefensible. Their other tactic for attracting support is to promise countries that the ITU is going to do something about reclaiming the international telephone calling fees that have been lost as the public telephone system has been effectively disintermediated. At this point a split in the DNS root is more than inevitable, it has already taken place. I would prefer to know how the split is implemented from a technical point of view rather than have to try to work it out. People can fuss over whether this is a good or a bad thing, but the countries that are looking to censor their net to avoid criticism of their regimes are going to be doing that with or without approval here. The IETF can approve the draft and have the state control faction claim that they have IETF endorsement of their scheme or if it is rejected they will use the rejection as 'proof' of the 'need' to develop standards in ITU instead. This is not an unprecedented fight either. There were/are similar fights over MAC address assignments and over barcodes and currently there are similar fights over RFID. The barcode system we use today was created by the Europeans super-setting the US scheme after they found the US organization's terms ridiculous and unacceptable. I think that eventually we will have a flat DNS where everyone is able to register in the root zone at the same cost as present .com domains or at the most the cost of an EV cert and with the same level of reliability, service etc. The whole concept of hierarchical partitioning of the namespace was bogus from the start. RealNames had the right concept but the wrong business model. For any scheme like that to be viable, there has to be an open registration model. Open up the root zone completely and many of the problems created by domain name squatting either go away or are drastically reduced in scope. Eventually the public delegation points outside the root would wither away. companies will not need to get worked up about crooks registering their name in every random TLD that is given a taxi badge by ICANN. -- Website: http://hallambaker.com/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 07:50:19 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7457621F8704; Fri, 29 Jun 2012 07:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340981419; bh=/tuiFRyD1f9c2gph9OtTYeuKeZKC+YsAnaFY0RRP96c=; h=References:In-Reply-To:Mime-Version:Message-Id:From:Date:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=qBoCcvrK+Xw+8uocWhXUfsb+Eau0Df/FHFQIG/fHpxPg0azk+9YnvkgSTs0K/6vA8 +7hEN+Mu2UXhHT5/6sl9OMITizQ+Zx2hoGV4HsfG423RkK5ep7jeQU3o3MnSxCgFUX adloAXY/UFdInBBs83jfY7ODs9cnsehEtjUrF438= 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 1CE6A21F874F for ; Fri, 29 Jun 2012 07:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.301 X-Spam-Level: *** X-Spam-Status: No, score=3.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 Q9Vy+k15VZLP for ; Fri, 29 Jun 2012 07:50:10 -0700 (PDT) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4674921F8675 for ; Fri, 29 Jun 2012 07:50:09 -0700 (PDT) Received: from [83.149.9.163] (account dburk@burkov.aha.ru HELO [10.196.99.243]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 304224985; Fri, 29 Jun 2012 18:50:05 +0400 References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPhone Mail (9B206) From: Dmitry Burkov Date: Fri, 29 Jun 2012 16:48:21 +0200 To: Phillip Hallam-Baker Cc: DNSEXT Working Group 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Don't call devil. Despite all obsolete contributions - Russian representatives never proposed to split dns root. Sent from my iPhone On 29.06.2012, at 16:31, Phillip Hallam-Baker wrote: > Those of us who have been watching the moves by Russia and China for > some time, in particular their proposals into the Dubai ITU meeting > have been expecting something of the sort for some time. > > The draft in question is simply describing a capability that the > Chinese have had deployed for at least five years, albeit maybe in a > different technical form. > > People have been proposing splitting from ICANN since before there was > an ICANN. And when the CEO is being paid close to a million dollars a > year and the whole operation is being driven by rent seeking, I think > many of the people behind those proposals might be seen as prescient, > if not for the fact that many of them were looking to achieve a bit of > rent seeking of their own. > > CABForum is currently looking at the bad things that could happen if > .corp is allowed. It turns out that a large number of corporations > already use this internally. Now leaving aside the technical > considerations, I do not think that CABForum should have to pay > $17,000 to make a formal objection on security grounds. > > Of course Russia and China are going to find plenty of other countries > to support their position when the status quo is indefensible. Their > other tactic for attracting support is to promise countries that the > ITU is going to do something about reclaiming the international > telephone calling fees that have been lost as the public telephone > system has been effectively disintermediated. > > At this point a split in the DNS root is more than inevitable, it has > already taken place. I would prefer to know how the split is > implemented from a technical point of view rather than have to try to > work it out. > > People can fuss over whether this is a good or a bad thing, but the > countries that are looking to censor their net to avoid criticism of > their regimes are going to be doing that with or without approval > here. > > The IETF can approve the draft and have the state control faction > claim that they have IETF endorsement of their scheme or if it is > rejected they will use the rejection as 'proof' of the 'need' to > develop standards in ITU instead. > > > This is not an unprecedented fight either. There were/are similar > fights over MAC address assignments and over barcodes and currently > there are similar fights over RFID. The barcode system we use today > was created by the Europeans super-setting the US scheme after they > found the US organization's terms ridiculous and unacceptable. > > I think that eventually we will have a flat DNS where everyone is able > to register in the root zone at the same cost as present .com domains > or at the most the cost of an EV cert and with the same level of > reliability, service etc. The whole concept of hierarchical > partitioning of the namespace was bogus from the start. RealNames had > the right concept but the wrong business model. For any scheme like > that to be viable, there has to be an open registration model. > > Open up the root zone completely and many of the problems created by > domain name squatting either go away or are drastically reduced in > scope. Eventually the public delegation points outside the root would > wither away. companies will not need to get worked up about crooks > registering their name in every random TLD that is given a taxi badge > by ICANN. > > -- > Website: http://hallambaker.com/ > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 08:12:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AB321F8724; Fri, 29 Jun 2012 08:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340982749; bh=R+9OE9gUhkV2vdbttYwshfhJ1eDAD4N7nnuBtjz303k=; h=Message-Id:From:To:In-Reply-To:Mime-Version:Date:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=NydxdFI/6L941IIJVDsYuFtjIc1Vr9ARqaQ/ccEzWiJUzOAzvDTH8OynIQpz3hOLM HGGsq7x1pBL8PGL3sQwmfQGXbhKO36Y1g1o2czVicpsPzK7saD5RjJ3f6V2YbzXu2P IQ8mdnk2h2xSqsTxtm5PzNdfYy9nUMfxTT/qDjAM= 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 85E2A21F8724 for ; Fri, 29 Jun 2012 08:12:27 -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 0haWp7nu-nK9 for ; Fri, 29 Jun 2012 08:12:27 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6B21F8615 for ; Fri, 29 Jun 2012 08:12:26 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 9629BCBC41D; Fri, 29 Jun 2012 16:12:24 +0100 (BST) Message-Id: From: Jim Reid To: Phillip Hallam-Baker In-Reply-To: Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jun 2012 16:12:24 +0100 References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> X-Mailer: Apple Mail (2.936) Cc: DNSEXT Working Group 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 29 Jun 2012, at 15:31, Phillip Hallam-Baker wrote: ... lengthy religious and out of scope rant deleted ... Please take your layer 9+ arguments elsewhere. They are not appropriate for this list or WG. Thanks. Let's focus on the matter at hand. Is this draft technically sound? Does it have engineering merit? If so, it's due proper consideration. If not, it dies. It's that simple. IMO, this draft is a remarkably bad idea and does not deserve any attention by the WG. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 08:18:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5882621F86E5; Fri, 29 Jun 2012 08:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340983132; bh=W1JqbKRooA/VDSGa0Y5GMnzByEpUIgUY0FKme5Meu9Q=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mMm1kCtVAniGnSAEQJkq89BvAyQXec9tqcRvwHxBGe+teawNGVXIO+aM/OcyQVYxk lwR6hPMaf3BmsQqYbnWbp8df+MF6FEYCJ3qiiCEpTT9068g8U0Gc0oNmWLPDbazFWm WDEv8OGMfuLiao3zvnyBtkQ4rsD9lYnzqVIkTnrE= 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 C709421F86E5 for ; Fri, 29 Jun 2012 08:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5Uxw+qD-XNPc for ; Fri, 29 Jun 2012 08:18:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C76E421F86D1 for ; Fri, 29 Jun 2012 08:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1340983128; x=1342192728; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1Ln6IuYE2rxXBa9ZDrSJMPYNECyvaD25NYMNgqglhm0=; b=K/zbR8MtE2eLbHXBcTzXG0mQ3b8GWs2HcPehP2OLKug6Ydn3ufjLZ1V0 HmMPTG7d9v3dmcq4SJCkgCgnA99XlUU/120h1B/OFKYfcttJvljKpwAIx nFEJSDZEpqtkZdH/4NHcEGmS8AmAKS05sZhL4ez46OmdrKfWAApNo6/+9 Y=; X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="94302381" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jun 2012 15:18:48 +0000 Received: from [161.44.65.173] ([161.44.65.173]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5TFIlP2024967; Fri, 29 Jun 2012 15:18:48 GMT Mime-Version: 1.0 (Apple Message framework v1278) From: Ralph Droms In-Reply-To: Date: Fri, 29 Jun 2012 11:18:47 -0400 Message-Id: <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> To: Jim Reid X-Mailer: Apple Mail (2.1278) Cc: DNSEXT Working Group 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Jun 29, 2012, at 11:12 AM 6/29/12, Jim Reid wrote: > On 29 Jun 2012, at 15:31, Phillip Hallam-Baker wrote: > > ... lengthy religious and out of scope rant deleted ... > > Please take your layer 9+ arguments elsewhere. They are not appropriate for this list or WG. Thanks. > > Let's focus on the matter at hand. Is this draft technically sound? Does it have engineering merit? If so, it's due proper consideration. If not, it dies. It's that simple. > > IMO, this draft is a remarkably bad idea and does not deserve any attention by the WG. Agreed that it's a bad idea. Can you be more specific - why is it not technically sound and lacking in engineering merit? I ask to provide support for any decision not to pursue this work in the IETF. - Ralph > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 08:32:24 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E082D21F8778; Fri, 29 Jun 2012 08:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340983944; bh=rohcep6+ZsBJu27oBn2/62tFcD/r0VKdsJe5kDhlTSo=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=XDgi/DsooKSimuspJPicwmaI8cKoQYRpd6951QZbBVNa4kXmtlbIupjbfZiaJ4Psx KpXCy0LSosYnmV9nli07uNECxG3il1MFPoG/HZyzCjJUkC/696PbpgbzYr5NX8Mfjj yRb8X7T8h2o4IHIuGnc5K++AGewrKYS4IzWC1T+E= 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 68CEF21F8702 for ; Fri, 29 Jun 2012 08:32:22 -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 fombB8PMYoWh for ; Fri, 29 Jun 2012 08:32:21 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id B80D021F8778 for ; Fri, 29 Jun 2012 08:32:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 4E9332C400D; Fri, 29 Jun 2012 08:32:21 -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 SVlPeWBsTAk4; Fri, 29 Jun 2012 08:32:20 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C1C222C4002; Fri, 29 Jun 2012 08:32:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) From: Nicholas Weaver In-Reply-To: <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> Date: Fri, 29 Jun 2012 08:32:20 -0700 Message-Id: References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1278) Cc: DNSEXT Working Group 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Jun 29, 2012, at 8:18 AM, Ralph Droms wrote: > Agreed that it's a bad idea. Can you be more specific - why is it not technically sound and lacking in engineering merit? > > I ask to provide support for any decision not to pursue this work in the IETF. It is fundamentally incompatible with DNSSEC, as DNSSEC, in practice, relies on knowing A root key. It is fundamentally incompatible with the concept of names being global: that is, example.com is controlled by the same entity when observed anywhere in the world. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 08:39:29 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2121F86F0; Fri, 29 Jun 2012 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340984369; bh=GuTz1AC1iBF5pIR8zfymCz62NjdRWvVE64ILfAhqkyY=; h=Message-Id:From:To:In-Reply-To:Mime-Version:Date:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=twuriEmIjm17PIkm/6BlTudUYe5t2k/qTSU6lOKgEKQkcCAuCsMVCUPm8cQ834W37 VrPCw+IS1OUNFWO4hsiGZpEyc227oWzWVTgvFmJa+/USjeECkE/X32MO8sKB/kJwO5 erAJfjExlpgb/QfEr+TG2q10uSg1gdQJxAdQ2XY4= 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 A6DA321F86F0 for ; Fri, 29 Jun 2012 08:39:28 -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 5VUzX75qvaQ7 for ; Fri, 29 Jun 2012 08:39:28 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id EC25921F86DE for ; Fri, 29 Jun 2012 08:39:27 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id D4200CBC41C; Fri, 29 Jun 2012 16:39:26 +0100 (BST) Message-Id: From: Jim Reid To: Ralph Droms In-Reply-To: <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jun 2012 16:39:26 +0100 References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DNSEXT Working Group 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 29 Jun 2012, at 16:18, Ralph Droms wrote: > Can you be more specific - why is it not technically sound and > lacking in engineering merit? Sure. The DNS uses hierarchical naming. Intrinsic to such a system is a unique root. It's the only way to ensure there's a universally consistent name space, something that's so self-evident it should not need further exposition. Any proposal for "multiple roots" by definition violate that fundamental principle. QED. It is also unclear what requirements or operating conditions lie behind this draft. So unless the WG has a better understanding of the problem the draft intends to solve, it is not known from a technical or engineering perspective if the proposed approach satisfies the preconditions that motivated the production of this draft. I suggest we ask the authors of this draft to come back when they have clarified the problem that apparently needs solving and they have devised a scheme which provides the innovation in the name space they appear to need and is consistent with RFC2826. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 11:24:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81D421F8838; Fri, 29 Jun 2012 11:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340994255; bh=dfW2QrT7z3PXcwcB6+dn355Hr62v1Aw0CwOimgOWLjg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=mArAU4xBA5pFV6bVt76sQz2HF4kNmpICz+9LNMAg6X6IMbW3p20VHT4asQzVSVa9W j2qEDwWkcZBh437JtTV5rsruwGQTfac7e3t/UWWYjuU6oAwIUlEFmnoZp68vNBMY7B q4h67WRdkxkxtNNcSxJkkiZESid+oPx7wkttopRI= 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 359B921F8838 for ; Fri, 29 Jun 2012 11:24:14 -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=[AWL=0.000, 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 6J2lGOxSnZfs for ; Fri, 29 Jun 2012 11:24:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE121F877C for ; Fri, 29 Jun 2012 11:24:11 -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 q5TIO8Us027174; Fri, 29 Jun 2012 14:24:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FEDF2C7.7030209@ogud.com> Date: Fri, 29 Jun 2012 14:24:07 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Donald Eastlake References: <201206141304.PAA00956@TR-Sys.de> In-Reply-To: X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 28/06/2012 22:16, Donald Eastlake wrote: > Hi Alfred, > > On Thu, Jun 14, 2012 at 9:04 AM, Alfred H=CEnes wrote: >> ... >> >> (1) Section 3.1.4 and/or Appendix B >> >> Maybe the IESG will call for a citation for closing the AFSDB >> sub-registry. RFC 5864 is the proper reference (and its author has >> approved the formal closing after checking with the AFS community). > > Adding such a reference seems reasonable. I suggest that, just before > the last sentence of the first paragraph in Section 3.1.4, adding "Use > of the AFSDB RR to locate AFS cell database servers was deprecated by > [RFC5864]." and noting this addition in Appendix B. > >> (2) Section 3.2 >> >> In the RCODE registry (Section 2.3), there is an apparent >> overloading of RCODE=3D16: >> BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845). > > Yes. But it seems unlikely to cause a problem as one is only used in > OPT and one s only used in TSIG. > >> Looking back into RFC 2845, it seems that the clerical error >> has happened at IANA when acting upon the assignments in that RFC. >> The second paragraph of Section 7 of RFC 2845 (on top of page 13) >> clearly states: >> >> ! IANA is expected to create and maintain a registry of "TSIG Error >> ! values" to be used for "Error" values as defined in section 2.3. >> ! Initial values should be those defined in section 1.7. New TSIG >> ! error codes for the TSIG error field are assigned using the IETF >> ! Consensus policy defined in RFC 2434. >> >> Note that the TSIG Error field is a component of TSIG RDATA distinct >> from the RCODE field in the DNS message header and its extension in >> OPT RRs. An According to RFC 2845 (which seems to be mostly unaware >> of EDNS, besides references to binary labels), there is an intentional >> semantical overlap for Error values 0..15, which are specified as being >> identical with the non-extended RCODES (0..15) in sect. 1.7 of RFC 2845; >> the "new" TSIG Error values 16..18 are to be signaled together with >> RCODE =3D NotAuth(9) (originally specified in RFC 2136). >> The idea there obviously was to make TSIG independent of the OPT RR, >> i.e. to allow TSIG without EDNS, but to this end RFC 2845 likely better >> had accomodated the extended RCODE BADVERS(16) assigned by RFC 2671 and >> chosen Error values 17..19 for TSIG purposes. > > Of course, your quote from the IANA Considerations of RFC 2845 (TSG) > is correct; however, I do not think the evidence is all on your side. > In particular, earlier in RFC 2845, the error field is described as an > "expanded RCODE". This is essentially the same term that RFC 2671 > (OPT) uses ("an extended RCODE") and the same term that RFC 2930 > (TKEY) uses ("The error code field is an extended RCODE."). > >> However, IANA obviously has registered the actual new values 16..18 >> in the RCODE registry and _not_ established a TSIG Error code registry. >> Mistakes happen, and it also may be wise to have RCODE values 17 and 18 >> "reserved" so that additional overloading cannot arise in the future. >> >> But IMO it would be worth adding "[*]" to the three RCODE registry >> entries based on RFC 2845: BADSIG, BADKEY, and BADTIME, e.g.: >> >> 16 BADSIG TSIG Signature Failure [*] [RFC2845] >> 17 BADKEY Key not recognized [*] [RFC2845] >> 18 BADTIME Signature out of time window [*] [RFC2845] >> >> ... and to add a footnote to the rigistry that says (e.g.): >> >> [*] These values are only to be used in the Error field of TSIG RRs; >> they cannot appear in the (extended) RCODE field of OPT RRs. >> >> Also, for added precision and consistency with RFC 2845 and RFC 2930, >> the last clause in the first paragraph of Section 2.3 should perhaps >> be adjusted as follows: >> >> OLD: >> and the TSIG and TKEY RRs have a 16-bit RCODE field. >> ^^^^^ >> NEW: >> and the TSIG and TKEY RRs have a 16-bit Error field. >> ^^^^^ > > I believe that the more different DNS error registries there are, the > more confusion and the more future errors in assignment will occur. > Except for the values of the 4-bit DNS header un-extended RCODE, for > which precious few free values exist, there is an abundance of values > available, so there is no scarcity reason for separate registries with > potentially overlapping values. It is also the case that a single > unified number space for DNS errors has been presented for years in > RFC 6195, RFC 5395, and RFC 2929 for use in the unextended DNS header, > the OPT extended DNS header, the TSIG RR error field, and the TKEY > error field. In all these years, no one has had a problem with there > being a single, unified DNS error number space. So, to the extent that > there is any consensus among these document I believe it is for the > simpler model of a single number space. > > To the extent that there s any ambiguity here, I would prefer to > resolve it by adding text to Section 2.3 of the rfc6195bis draft like > the following: "To the extent that any prior RFCs imply any sort of > different error number space for the OPT, TSIG, or TKEY RRs, they are > superseded by this unified DNS error number space. With the existing > exception of error number 16, the same error number MUST NOT be > assigned for different errors even if they would occur in different RR > types." > As one of perpetrators of this confusion and historian of what happened. The IANA processing of RFC2671 was a unmitigated disaster, OPT got allocated 41 which should have been 25x code All the other assignments from the document did not take place (more = below) TSIG RFC2845 editors assumed single RCODE space but because of IANA = mistake in processing 2671 we overlooked the double RCODE. The = inconsistent wording reflects that different people edited different = versions and the processes of document review in the WG were not up to = the same standards as today. I think Donald's solution is the most appropriate one, Alfred thanks for brining this up and enabling us to once for all close = down this confusion. This happened before I became a co-chair of DNSIND but within 10 minutes = of the RFC2671 announcement I raised the issue of OPT allocation code, = but missed the omissions in IANA processing. If I had noticed that as well I think we would have had a good case to = reissue the RFC as RFC2671.1. To be fair to IANA the IANA actions in RFC2671 were badly stated and = well hidden in the text thus I do not blame IANA solely for this as none = of the Editors, Chairs, AD's and RFC-editor did notice that the = processing did not take place. This was one of the triggers in putting = more formal process in allocations, IANA considerations sections, = external reviews for IANA actions, ID proto writeup etc. = Olafur _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Jun 29 12:23:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCF21F8866; Fri, 29 Jun 2012 12:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1340997819; bh=slM1McrV1EuvIbDwep6eoKWXYAw81qJTwJpzufFbybc=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RayiE5Q9MxsfiEiVKpYqIaWNrOLE+flTz+qqKpnCGKegQZ14btuFqYowU9ZpzWl8A dCa2lV4Megos9iOH4PGBe2z0NhIKiudI6so7HQmKV/DFndMWi+uyBMEiy/Vl3t3q5h W3zYYK2sfvVhPK7NdhMX9SqlonI/Qa9cWG9wd2EM= 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 91A0721F885C for ; Fri, 29 Jun 2012 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.555 X-Spam-Level: X-Spam-Status: No, score=-98.555 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 fjzlqv2YCQNE for ; Fri, 29 Jun 2012 12:23:36 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id E665D21F86FC for ; Fri, 29 Jun 2012 12:23:34 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA047157710; Fri, 29 Jun 2012 21:21:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA03796; Fri, 29 Jun 2012 21:21:48 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201206291921.VAA03796@TR-Sys.de> To: d3e3e3@gmail.com Date: Fri, 29 Jun 2012 21:21:48 +0200 (MESZ) In-Reply-To: from Donald Eastlake at Jun "28, " 2012 "10:16:10" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org, ogud@ogud.com 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org RG9uYWxkLAp0aGFua3MgZm9yIHlvdXIgdG91Z2h0cyBhbmQgeW91ciByZXNwb25zZS4KQW5kIGFs c28gdGhhbmtzIHRvIE9sYWZ1ciBmb3IgaGlzIGVubGlnaHRlbmluZyBoaXN0b3JpY2FsIG5vdGVz IQooSSBmb2xsb3cgdXAgdG8gRG9uYWxkJ3MgbWVzc2FnZSBiZWxvdywgYnV0IEkgaW5jbHVkZSBy ZWZlcmFscwp0byBPbGFmdXIncyBzdGF0ZW1lbnQuKQoKQXQgSnVuIDJSOSwgMjAxMiwgRG9uYWxk IEVhc3RsYWtlIDNyZCB3cm90ZToKCj4gIEhpIEFsZnJlZCwKPgo+IE9uIFRodSwgSnVuIDE0LCAy MDEyIGF0IDk6MDQgQU0sIDxhaEB0ci1zeXMuZGU+IHdyb3RlOgo+PiAuLi4KPj4KPj4gKDEpIKBT ZWN0aW9uIDMuMS40IGFuZC9vciBBcHBlbmRpeCBCCj4+Cj4+IE1heWJlIHRoZSBJRVNHIHdpbGwg Y2FsbCBmb3IgYSBjaXRhdGlvbiBmb3IgY2xvc2luZyB0aGUgQUZTREIKPj4gc3ViLXJlZ2lzdHJ5 LiCgUkZDIDU4NjQgaXMgdGhlIHByb3BlciByZWZlcmVuY2UgKGFuZCBpdHMgYXV0aG9yIGhhcwo+ PiBhcHByb3ZlZCB0aGUgZm9ybWFsIGNsb3NpbmcgYWZ0ZXIgY2hlY2tpbmcgd2l0aCB0aGUgQUZT IGNvbW11bml0eSkuCj4KPiBBZGRpbmcgc3VjaCBhIHJlZmVyZW5jZSBzZWVtcyByZWFzb25hYmxl LiBJIHN1Z2dlc3QgdGhhdCwganVzdCBiZWZvcmUKPiB0aGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUg Zmlyc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMy4xLjQsIGFkZGluZyAiVXNlCj4gb2YgdGhlIEFG U0RCIFJSIHRvIGxvY2F0ZSBBRlMgY2VsbCBkYXRhYmFzZSBzZXJ2ZXJzIHdhcyBkZXByZWNhdGVk IGJ5Cj4gW1JGQzU4NjRdLiIgYW5kIG5vdGluZyB0aGlzIGFkZGl0aW9uIGluIEFwcGVuZGl4IEIu CgpBZ3JlZWQuCgoKPj4gKDIpIKBTZWN0aW9uIDMuMgo+Pgo+PiBJbiB0aGUgUkNPREUgcmVnaXN0 cnkgKFNlY3Rpb24gMi4zKSwgdGhlcmUgaXMgYW4gYXBwYXJlbnQKPj4gb3ZlcmxvYWRpbmcgb2Yg UkNPREU9MTY6Cj4+IKAgQkFEVkVSUyAoUkZDIDI2NzEgLyBSRkMgMjY3MWJpcykgdnMuIEJBRFNJ RyAoUkZDIDI4NDUpLgo+Cj4gWWVzLiBCdXQgaXQgc2VlbXMgdW5saWtlbHkgdG8gY2F1c2UgYSBw cm9ibGVtIGFzIG9uZSBpcyBvbmx5IHVzZWQgaW4KPiBPUFQgYW5kIG9uZSBzIG9ubHkgdXNlZCBp biBUU0lHLgoKWW91IHNwZWxsIGl0IG91dCBzbyBzaG9ydCBhbmQgcHJlY2lzZWx5IHRoYXQgaXQg d291bGQgYmUgYSBwaXR5CnRvIGxvc2UgdGhhdCBjbGFyaWZpY2F0aW9uLiAgU2VlIG15IGFkZGl0 aW9uYWwgc3VnZ2VzdGlvbiBiZWxvdy4KCj4KPj4gTG9va2luZyBiYWNrIGludG8gUkZDIDI4NDUs IGl0IHNlZW1zIHRoYXQgdGhlIGNsZXJpY2FsIGVycm9yCj4+IGhhcyBoYXBwZW5lZCBhdCBJQU5B IHdoZW4gYWN0aW5nIHVwb24gdGhlIGFzc2lnbm1lbnRzIGluIHRoYXQgUkZDLgo+PiBUaGUgc2Vj b25kIHBhcmFncmFwaCBvZiBTZWN0aW9uIDcgb2YgUkZDIDI4NDUgKG9uIHRvcCBvZiBwYWdlIDEz KQo+PiBjbGVhcmx5IHN0YXRlczoKPj4KPj4gISCgSUFOQSBpcyBleHBlY3RlZCB0byBjcmVhdGUg YW5kIG1haW50YWluIGEgcmVnaXN0cnkgb2YgIlRTSUcgRXJyb3IKPj4gISCgdmFsdWVzIiB0byBi ZSB1c2VkIGZvciAiRXJyb3IiIHZhbHVlcyBhcyBkZWZpbmVkIGluIHNlY3Rpb24gMi4zLgo+PiAh IKBJbml0aWFsIHZhbHVlcyBzaG91bGQgYmUgdGhvc2UgZGVmaW5lZCBpbiBzZWN0aW9uIDEuNy4g oE5ldyBUU0lHCj4+ICEgoGVycm9yIGNvZGVzIGZvciB0aGUgVFNJRyBlcnJvciBmaWVsZCBhcmUg YXNzaWduZWQgdXNpbmcgdGhlIElFVEYKPj4gISCgQ29uc2Vuc3VzIHBvbGljeSBkZWZpbmVkIGlu IFJGQyAyNDM0Lgo+Pgo+PiBOb3RlIHRoYXQgdGhlIFRTSUcgRXJyb3IgZmllbGQgaXMgYSBjb21w b25lbnQgb2YgVFNJRyBSREFUQSBkaXN0aW5jdAo+PiBmcm9tIHRoZSBSQ09ERSBmaWVsZCBpbiB0 aGUgRE5TIG1lc3NhZ2UgaGVhZGVyIGFuZCBpdHMgZXh0ZW5zaW9uIGluCj4+IE9QVCBSUnMuIKBB biBBY2NvcmRpbmcgdG8gUkZDIDI4NDUgKHdoaWNoIHNlZW1zIHRvIGJlIG1vc3RseSB1bmF3YXJl Cj4+IG9mIEVETlMsIGJlc2lkZXMgcmVmZXJlbmNlcyB0byBiaW5hcnkgbGFiZWxzKSwgdGhlcmUg aXMgYW4gaW50ZW50aW9uYWwKPj4gc2VtYW50aWNhbCBvdmVybGFwIGZvciBFcnJvciB2YWx1ZXMg MC4uMTUsIHdoaWNoIGFyZSBzcGVjaWZpZWQgYXMgYmVpbmcKPj4gaWRlbnRpY2FsIHdpdGggdGhl IG5vbi1leHRlbmRlZCBSQ09ERVMgKDAuLjE1KSBpbiBzZWN0LiAxLjcgb2YgUkZDIDI4NDU7Cj4+ IHRoZSAibmV3IiBUU0lHIEVycm9yIHZhbHVlcyAxNi4uMTggYXJlIHRvIGJlIHNpZ25hbGVkIHRv Z2V0aGVyIHdpdGgKPj4gUkNPREUgPSBOb3RBdXRoKDkpIChvcmlnaW5hbGx5IHNwZWNpZmllZCBp biBSRkMgMjEzNikuCj4+IFRoZSBpZGVhIHRoZXJlIG9idmlvdXNseSB3YXMgdG8gbWFrZSBUU0lH IGluZGVwZW5kZW50IG9mIHRoZSBPUFQgUlIsCj4+IGkuZS4gdG8gYWxsb3cgVFNJRyB3aXRob3V0 IEVETlMsIGJ1dCB0byB0aGlzIGVuZCBSRkMgMjg0NSBsaWtlbHkgYmV0dGVyCj4+IGhhZCBhY2Nv bW9kYXRlZCB0aGUgZXh0ZW5kZWQgUkNPREUgQkFEVkVSUygxNikgYXNzaWduZWQgYnkgUkZDIDI2 NzEgYW5kCj4+IGNob3NlbiBFcnJvciB2YWx1ZXMgMTcuLjE5IGZvciBUU0lHIHB1cnBvc2VzLgo+ Cj4gT2YgY291cnNlLCB5b3VyIHF1b3RlIGZyb20gdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgb2Yg UkZDIDI4NDUgKFRTRykKPiBpcyBjb3JyZWN0OyBob3dldmVyLCBJIGRvIG5vdCB0aGluayB0aGUg ZXZpZGVuY2UgaXMgYWxsIG9uIHlvdXIgc2lkZS4KPiBJbiBwYXJ0aWN1bGFyLCBlYXJsaWVyIGlu IFJGQyAyODQ1LCB0aGUgZXJyb3IgZmllbGQgaXMgZGVzY3JpYmVkIGFzIGFuCj4gImV4cGFuZGVk IFJDT0RFIi4gIFRoaXMgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgdGVybSB0aGF0IFJGQyAyNjcx Cj4gKE9QVCkgdXNlcyAoImFuIGV4dGVuZGVkIFJDT0RFIikgYW5kIHRoZSBzYW1lIHRlcm0gdGhh dCBSRkMgMjkzMAo+IChUS0VZKSB1c2VzICgiVGhlIGVycm9yIGNvZGUgZmllbGQgaXMgYW4gZXh0 ZW5kZWQgUkNPREUuIikuCgpOZXZlcnRoZWxlc3MsIHRoZSBmaWVsZCBpbiB0aGUgVFNJRyBSREFU QSBpcyBkZW5vdGVkICJFcnJvciIsCmFuZCBpdCBtaWdodCBiZSB3b3J0aCBzdGF5aW5nIGxpdGVy YWxseSB3aXRoIHRoYXQsIHRvIGF2b2lkCmNvbmZ1c2lvbi4KCj4KPj4gSG93ZXZlciwgSUFOQSBv YnZpb3VzbHkgaGFzIHJlZ2lzdGVyZWQgdGhlIGFjdHVhbCBuZXcgdmFsdWVzIDE2Li4xOAo+PiBp biB0aGUgUkNPREUgcmVnaXN0cnkgYW5kIF9ub3RfIGVzdGFibGlzaGVkIGEgVFNJRyBFcnJvciBj b2RlIHJlZ2lzdHJ5Lgo+PiBNaXN0YWtlcyBoYXBwZW4sIGFuZCBpdCBhbHNvIG1heSBiZSB3aXNl IHRvIGhhdmUgUkNPREUgdmFsdWVzIDE3IGFuZCAxOAo+PiAicmVzZXJ2ZWQiIHNvIHRoYXQgYWRk aXRpb25hbCBvdmVybG9hZGluZyBjYW5ub3QgYXJpc2UgaW4gdGhlIGZ1dHVyZS4KPj4KPj4gQnV0 IElNTyBpdCB3b3VsZCBiZSB3b3J0aCBhZGRpbmcgIlsqXSIgdG8gdGhlIHRocmVlIFJDT0RFIHJl Z2lzdHJ5Cj4+IGVudHJpZXMgYmFzZWQgb24gUkZDIDI4NDU6IEJBRFNJRywgQkFES0VZLCBhbmQg QkFEVElNRSwgZS5nLjoKPj4KPj4goCCgIKAgoDE2IKAgoEJBRFNJRyCgIKBUU0lHIFNpZ25hdHVy ZSBGYWlsdXJlIFsqXSCgIKAgoCCgIFtSRkMyODQ1XQo+PiCgIKAgoCCgMTcgoCCgQkFES0VZIKAg oEtleSBub3QgcmVjb2duaXplZCBbKl0goCCgIKAgoCCgIKAgW1JGQzI4NDVdCj4+IKAgoCCgIKAx OCCgIKBCQURUSU1FIKAgU2lnbmF0dXJlIG91dCBvZiB0aW1lIHdpbmRvdyBbKl0goCBbUkZDMjg0 NV0KPj4KPj4gLi4uIGFuZCB0byBhZGQgYSBmb290bm90ZSB0byB0aGUgcmVnaXN0cnkgdGhhdCBz YXlzIChlLmcuKToKPj4KPj4goCBbKl0gVGhlc2UgdmFsdWVzIGFyZSBvbmx5IHRvIGJlIHVzZWQg aW4gdGhlIEVycm9yIGZpZWxkIG9mIFRTSUcgUlJzOwo+PiCgIKAgoCB0aGV5IGNhbm5vdCBhcHBl YXIgaW4gdGhlIChleHRlbmRlZCkgUkNPREUgZmllbGQgb2YgT1BUIFJScy4KClNvLCBpbiBhIHNl cXVlbCB0byB3aGF0IEkgc2FpZCBhYm92ZSwgbWF5YmUgaXQgd291bGQgYmUgd29ydGgKdG8gYWN0 dWFsbHkgaGF2ZSB0aGlzIGZvb3Rub3RlIGluIHRoZSByZWdpc3RyeS4gIEV4cGxhaW5pbmcgaW4K YSBzZWNvbmQgZm9vdG5vdGUgKGFuZCB0aGVyZWJ5IHR1cm5pbmcgdGhlc2UgaW50byBudW1iZXJl ZCBub3RlcykKdGhhdCBCQURWRVJTIGlzIHRvIGFwcGVhciBpbiB0aGUgT1BUIFJSIG9ubHkgc2hv dWxkIGJlIHdvcnRoCmNvbnNpZGVyaW5nLgoKTWFpbnRhaW5pbmcgdGhpcyBzdWdnZXN0aW9uIGlz IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlCmZ1bGwgbGVhZGluZyB0ZXh0IG9mIFNl Y3Rpb24gMi4zIChhcyBhbWVuZGVkIGJ5IHRoZSBjbGF1c2UgZ2l2ZW4KYmVsb3cpIHdpbGwgbm90 IGFwcGVhciBpbiB0aGUgSUFOQSByZWdpc3RyeSBmaWxlLCBhbmQgdGhhdCB0aGUKcmVnaXN0cnkg c2hvdWxkIGJlIHNvbWVob3cgc2VsZi1jb250YWluZWQgZm9yIHRoZSBiZW5lZml0IG9mCnVuc3Vz cGVjdGluZyByZWFkZXJzLgpIb3dldmVyLCBpZiBJQU5BIHdpbGwgYWN0dWFsbHkgY29weSB0aGUg ZW50aXJlIHByb3NlIHRleHQgYXMgYSBOT1RFCnRvIHRoZSBSQ09ERSByZWdpc3RyeSwgYWRtaXR0 ZWRseSB0aGVzZSBmb290bm90ZXMgYXJlIG5vdCBuZWVkZWQuCgo+Pgo+PiBBbHNvLCBmb3IgYWRk ZWQgcHJlY2lzaW9uIGFuZCBjb25zaXN0ZW5jeSB3aXRoIFJGQyAyODQ1IGFuZCBSRkMgMjkzMCwK Pj4gdGhlIGxhc3QgY2xhdXNlIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAyLjMg c2hvdWxkIHBlcmhhcHMKPj4gYmUgYWRqdXN0ZWQgYXMgZm9sbG93czoKPj4KPj4gT0xEOgo+PiCg IGFuZCB0aGUgVFNJRyBhbmQgVEtFWSBSUnMgaGF2ZSBhIDE2LWJpdCBSQ09ERSBmaWVsZC4KPj4g oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgXl5eXl4KPj4gTkVXOgo+ PiCgIGFuZCB0aGUgVFNJRyBhbmQgVEtFWSBSUnMgaGF2ZSBhIDE2LWJpdCBFcnJvciBmaWVsZC4K Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgXl5eXl4KClNvIGdp dmVuIHdoYXQgaXMgc2FpZCBhYm92ZSBhbmQgd2hhdCBPbGFmdXIgaGFzIGNvbmZpcm1lZCB0b2Rh eSwKSSBub3cgc2xpZ2h0bHkgbW9kaWZ5IG15IHN1Z2dlc3Rpb24gdG8gcGVyaGFwcyBiZXR0ZXIg c2F5OgoKTkVXOgogoCBhbmQgdGhlIFRTSUcgYW5kIFRLRVkgUlJzIGhhdmUgYSAxNi1iaXQgUkNP REUgZmllbGQgZGVzaWduYXRlZCBpbgogICB0aGUgcmVzcGVjdGl2ZSBSRkNzIGFzIHRoZSAiRXJy b3IiIGZpZWxkLgoKKFlvdSBtYXkgd29yZHNtaXRoIGlmIHlvdSBsaWtlLikKCj4gSSBiZWxpZXZl IHRoYXQgdGhlIG1vcmUgZGlmZmVyZW50IEROUyBlcnJvciByZWdpc3RyaWVzIHRoZXJlIGFyZSwg dGhlCj4gbW9yZSBjb25mdXNpb24gYW5kIHRoZSBtb3JlIGZ1dHVyZSBlcnJvcnMgaW4gYXNzaWdu bWVudCB3aWxsIG9jY3VyLgo+IEV4Y2VwdCBmb3IgdGhlIHZhbHVlcyBvZiB0aGUgNC1iaXQgRE5T IGhlYWRlciB1bi1leHRlbmRlZCBSQ09ERSwgZm9yCj4gd2hpY2ggcHJlY2lvdXMgZmV3IGZyZWUg dmFsdWVzIGV4aXN0LCB0aGVyZSBpcyBhbiBhYnVuZGFuY2Ugb2YgdmFsdWVzCj4gYXZhaWxhYmxl LCBzbyB0aGVyZSBpcyBubyBzY2FyY2l0eSByZWFzb24gZm9yIHNlcGFyYXRlIHJlZ2lzdHJpZXMg d2l0aAo+IHBvdGVudGlhbGx5IG92ZXJsYXBwaW5nIHZhbHVlcy4gIEl0IGlzIGFsc28gdGhlIGNh c2UgdGhhdCBhIHNpbmdsZQo+IHVuaWZpZWQgbnVtYmVyIHNwYWNlIGZvciBETlMgZXJyb3JzIGhh cyBiZWVuIHByZXNlbnRlZCBmb3IgeWVhcnMgaW4KPiBSRkMgNjE5NSwgUkZDIDUzOTUsIGFuZCBS RkMgMjkyOSBmb3IgdXNlIGluIHRoZSB1bmV4dGVuZGVkIEROUyBoZWFkZXIsCj4gdGhlIE9QVCBl eHRlbmRlZCBETlMgaGVhZGVyLCB0aGUgVFNJRyBSUiBlcnJvciBmaWVsZCwgYW5kIHRoZSBUS0VZ Cj4gZXJyb3IgZmllbGQuIEluIGFsbCB0aGVzZSB5ZWFycywgbm8gb25lIGhhcyBoYWQgYSBwcm9i bGVtIHdpdGggdGhlcmUKPiBiZWluZyBhIHNpbmdsZSwgdW5pZmllZCBETlMgZXJyb3IgbnVtYmVy IHNwYWNlLiBTbywgdG8gdGhlIGV4dGVudCB0aGF0Cj4gdGhlcmUgaXMgYW55IGNvbnNlbnN1cyBh bW9uZyB0aGVzZSBkb2N1bWVudCBJIGJlbGlldmUgaXQgaXMgZm9yIHRoZQo+IHNpbXBsZXIgbW9k ZWwgb2YgYSBzaW5nbGUgbnVtYmVyIHNwYWNlLgo+Cj4gVG8gdGhlIGV4dGVudCB0aGF0IHRoZXJl IHMgYW55IGFtYmlndWl0eSBoZXJlLCBJIHdvdWxkIHByZWZlciB0bwo+IHJlc29sdmUgaXQgYnkg YWRkaW5nIHRleHQgdG8gU2VjdGlvbiAyLjMgb2YgdGhlIHJmYzYxOTViaXMgZHJhZnQgbGlrZQo+ IHRoZSBmb2xsb3dpbmc6ICJUbyB0aGUgZXh0ZW50IHRoYXQgYW55IHByaW9yIFJGQ3MgaW1wbHkg YW55IHNvcnQgb2YKPiBkaWZmZXJlbnQgZXJyb3IgbnVtYmVyIHNwYWNlIGZvciB0aGUgT1BULCBU U0lHLCBvciBUS0VZIFJScywgdGhleSBhcmUKPiBzdXBlcnNlZGVkIGJ5IHRoaXMgdW5pZmllZCBE TlMgZXJyb3IgbnVtYmVyIHNwYWNlLiBXaXRoIHRoZSBleGlzdGluZwo+IGV4Y2VwdGlvbiBvZiBl cnJvciBudW1iZXIgMTYsIHRoZSBzYW1lIGVycm9yIG51bWJlciBNVVNUIE5PVCBiZQo+IGFzc2ln bmVkIGZvciBkaWZmZXJlbnQgZXJyb3JzIGV2ZW4gaWYgdGhleSB3b3VsZCBvY2N1ciBpbiBkaWZm ZXJlbnQgUlIKPiB0eXBlcy4iCgpZZXAuICBJbiB0aGUgbGlnaHQgb2YgT2xhZnVyJ3MgY29uZmly bWF0aW9uLCB0aGF0J3MgYSBnb29kIGFkZGl0aW9uLgoKSSBndWVzcyB0aGF0IGNvbnNlcXVlbnRp YWxseSB0aGUgZHJhZnQgc2hvdWxkIGJlIGxhYmVsbGVkIGFzIFVwZGF0aW5nClJGQ3MgMjg0NSBh bmQgMjkzMCBhcyB3ZWxsLCBhbmQgbWVudGlvbiB0aGlzIGluIHRoZSBBYnN0cmFjdCAoZHVlIHRv CmN1cnJlbnQgSUVTRyBwcmVmZXJlbmNlcykgYW5kIGluIEFwcGVuZGl4IEIgYXMgd2VsbC4KUkZD IDI5MzAgaXMgaW5jbHVkZWQgaGVyZSBiZWNhdXNlIGluIFNlY3Rpb24gMi42IG9mIHRoYXQgUkZD LCB0aGUKbGlzdGluZyBvZiBSQ09ERSB2YWx1ZXMgMTYuLjE4IGZvciB0aGUgVFNJRyBFcnJvciBm aWVsZCBpcyBtaXNsZWFkaW5nCmFuZCB0aGlzIGlzIGNsYXJpZmllZCBieSB0aGUgYWJvdmUgdGV4 dCBhZGRpdGlvbi4KCkJlc3QgcmVnYXJkcywKICBBbGZyZWQuCgoKPgo+IFRoYW5rcywKPiBEb25h bGQKPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+IKBEb25hbGQgRS4gRWFzdGxha2Ug M3JkoKAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQo+IKAxNTUgQmVhdmVyIFN0cmVldCygTWlsZm9y ZCwgTUEgMDE3NTcgVVNBCj4goGQzZTNlM0BnbWFpbC5jb20KPgo+Cj4+IEtpbmQgcmVnYXJkcywK Pj4goEFsZnJlZC4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Sat Jun 30 19:50:31 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4721F851B; Sat, 30 Jun 2012 19:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341111031; bh=Uf3OCQ+8IgmxKoz19Ur/1e+fwiTEczj/ldBlFN5/8kU=; h=Message-ID:Date:From:To:In-Reply-To:MIME-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=BvkUkhyA9mE4upTrGDRI1c3HGXpbCcyyo4FF+QRyFOteIcpWCry8MafBaQc+of466 xlRyBA44Yh5oCTQCta4EyU8+2coHRhl+/XYaBFtz/KaDjHHSPAkeQOTTHY05OycywJ jmlLGFOSUP94gOgNCLDD+H0L5NI+9yQLbBgHaiyM= 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 F38EC21F8551 for ; Sat, 30 Jun 2012 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_40=-0.185] 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 t9PHcOZaZPcn for ; Sat, 30 Jun 2012 19:50:28 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with SMTP id 002EF21F851B for ; Sat, 30 Jun 2012 19:50:27 -0700 (PDT) Received: from [98.139.212.144] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2012 02:50:29 -0000 Received: from [98.139.212.204] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2012 02:50:29 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 01 Jul 2012 02:50:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 214355.48021.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 91932 invoked by uid 60001); 1 Jul 2012 02:50:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1341111028; bh=64pVo5g0m+GUg8YUedZQdY5o9HnzN0epkXjRICDBdBQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gk00xSm0z4r6bsdQGvlY55mH8NjeG4MOK7vmsvK7FQbFVwgF8xrXtmriHZJk/be3igPf9E2yEH/Xw2SuCYf1MTlmG6DXcBroB2OfN1Hmv99rgFFt1F50Ax8o04S6qg9gXFZEOWkP0SZjoPO0fjj81qBxz7ChjKW3kwPVymmdgjk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xUxFXEBtBtzFGr0JJlzQ00I2c4soPxA/Lp7tu3neRlN+A9ED5MsoGbh7v3dfvy1W4ENSAKXYMwjcPPKB2NuAYRBmh1VL8X5Y5s4mbCgR5K8lOCmYBSA2VKpEZwEJmrZDtuk77UKsWQwfd7oZjJfSQ7KWuOMlNa4BtN+URD47Msk=; X-YMail-OSG: 4CHa4wQVM1nWDKFt0EIvIq4N.Y85mVpJ0AllBDUlTwOs3tL f1IHiu7j_VcbDO7uyQy3hh.16Y2w8cQtcapvqDytrL_rKJGavipQpWV3AD00 m1G8fPK2gM_GWqErHNAtQsdcH5a.g9rnK8BlSAPk6XRgf5S0kFGro3Aj9gSW 0u5qEN0drgD5E1TE.ntVtRmT4u2Xnq4RBWuT6HMEGAG3XC1rNpfx4kzeFVEL xClnKUhGQ9R9UJJIclqLZcRiL885uokNAyu4QMAxGi.R778W2jE38J9IlucS V1FNVgBKUWDr3ZPFbXTbF6OTatjwdU55RdDIs56Eu_gPpuNVeFbs1tO25iu7 4PMU.c2Ouevg3p_ngVQqegmu6pODA44tMFt2dUwIoIV8udMfN8G2eIy1YDZp JJytC8RXLDmbrzy5xfsDQBJNhCNH_JT1qOlCGYG6U7HABqf7MYlk_95d5WcA vUc6a6dRwltNsnD.t2Y3zVQr11GqNgVozGS5Lepq9mo5BgvoNbDi.IaI70XA T Received: from [113.111.211.180] by web161703.mail.bf1.yahoo.com via HTTP; Sat, 30 Jun 2012 19:50:28 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1341111028.69685.YahooMailClassic@web161703.mail.bf1.yahoo.com> Date: Sat, 30 Jun 2012 19:50:28 -0700 (PDT) From: YP Diao To: Stephane Bortzmeyer , Andrew Sullivan In-Reply-To: <20120619024945.GL32683@mail.yitter.info> MIME-Version: 1.0 Cc: draft-diao-aip-dns@tools.ietf.org, dnsext@ietf.org 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Yes, here is a super-root in this draft in mathematical sense. It is the wa= y to smoothly transfer to AIP DNS and provides DNS resolution among all the= se AIP networks. If we provide the domain name suffix, common sense is avai= lable globally. It satisfies the two essentail perconditions in RFC 2826: - The existence of a common symbol set, and - The existence of a common semantic interpretation of these symbols. But in practical you can run your own root in each AIP network. It provides= automony and extensibility. = Technically, it is extensible choice for countries, global operators, and s= pecific internet networks such as Things of Internet. Of course, there are more other applications as you need. Diao Yongping 20120701 = --- On Mon, 6/18/12, Andrew Sullivan wrote: > From: Andrew Sullivan > Subject: Re: [dnsext] draft-diao-aip-dns > To: "Stephane Bortzmeyer" > Cc: "Ond?ej Sur=FD" , teacherdddd@yahoo.com.cn, dnsex= t@ietf.org, 644247110@qq.com, diaoyp@yahoo.com > Date: Monday, June 18, 2012, 8:49 PM > 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.=A0 But the > DNS is a tree > in the mathematical sense.=A0 It is _incoherent_ to say > that you can > have multiple roots in such a tree.=A0 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.=A0 But a portion of the > draft will > never be possible to understand, because it is trying to > hide the > fundamental confusion at its core.=A0 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 > = _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext