From A.Hoenes@tr-sys.de Sun Mar 1 13:49:23 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FD23A6BED for ; Sun, 1 Mar 2009 13:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.844 X-Spam-Level: * X-Spam-Status: No, score=1.844 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p38p0j4Mi2Y0 for ; Sun, 1 Mar 2009 13:49:22 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 59D533A6BF4 for ; Sun, 1 Mar 2009 13:49:21 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA213534059; Sun, 1 Mar 2009 22:47:39 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA19476; Sun, 1 Mar 2009 22:47:38 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903012147.WAA19476@TR-Sys.de> To: ietf@hardakers.net, dnsop@ietf.org Date: Sun, 1 Mar 2009 22:47:37 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: dnsop-ads@tools.ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-name-server-management-reqs-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 21:49:23 -0000 Wes, Thanks for the updated I-D version, draft-ietf-dnsop-name-server-management-reqs-02. I see all my previous concerns and the last editorial nits addressed in this version. Folks, Beyond my personal PoV, I obeserve that I cannot recall any controversial issues left open on the list as well. Thus, I suggest that the chairs now undertake the appropriate steps to go ahead quickly with this document as well ! Otherwise, if you have objections, please speak up, indicate precisely your concerns and propose alternate text ! Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Sun Mar 1 14:49:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769023A6359 for ; Sun, 1 Mar 2009 14:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN4qql5Bn-Ap for ; Sun, 1 Mar 2009 14:49:02 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id AC1113A67F7 for ; Sun, 1 Mar 2009 14:49:01 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA213777653; Sun, 1 Mar 2009 23:47:33 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA19579; Sun, 1 Mar 2009 23:47:31 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903012247.XAA19579@TR-Sys.de> To: tglassey@earthlink.net Date: Sun, 1 Mar 2009 23:47:31 +0100 (MEZ) In-Reply-To: <49A94325.2080903@earthlink.net> from TSG at Feb "28, " 2009 "05:59:01" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-default-local-zones-07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 22:49:03 -0000 > Roy Arends wrote: >> On Feb 25, 2009, at 9:44 PM, Alfred HÎnes wrote: >> >>> Question to the WG : >>> ------------------ >>> >>> Are there any convincing reasons for *not* advancing that draft >>> in a reasonable timeframe now? >> >> I can't see any. >> >> Small terminology nit, but will burn a separate subject line for that >> to be thread safe. >> >> +1 for advancing that draft in a reasonable timeframe now. >> >> Roy > > Roy - I can see a reason - if you "block out" the IETF process rules > into a flow-chart you will find that the publishing of v08 of this draft > changed the v07 specification - and it MUST be fully vetted and then > interoperability proven for each new revision of the Protocol. > > Todd Glassey Todd, please do not inject misleading assertions. Generally, wordsmithing, fixing grammar/punctuation etc. in a few places of a draft, or -- as in this case -- improving the visual presentation and hence the readability of a table, and updating the references (obviously necessary after half a year of inactivity of the group and its chairs with regard to this document) can not be seen as "changing the specification". Even more, the missed editorial review now acted upon already had been out for the v06, around IETF in Dublin. It should be in the proper interest of the WG to deliver drafts in high editorial quality to the IESG, since doing so decreases the probability of having to respin a draft iteration for that purpose later, or even letting the RFC Editor fix that stuff. Indeed, all these changes could have been left to the RFC Editor, but if they don't have to, the processing is significantly speeded up, to the benefit of all -- and you can review the improved draft _before_ it is getting forwarded, so this way I believe the spirit of the IETF process is followed even better! Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From olaf@NLnetLabs.nl Mon Mar 2 03:27:05 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAC128C20E for ; Mon, 2 Mar 2009 03:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSTZNoVoF1eC for ; Mon, 2 Mar 2009 03:27:04 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 40D7D28C20A for ; Mon, 2 Mar 2009 03:27:04 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:21b:63ff:fe94:3816] ([IPv6:2001:7b8:206:1:21b:63ff:fe94:3816]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n22BRJXx094670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Mar 2009 12:27:25 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Message-Id: From: Olaf Kolkman To: dnsop@ietf.org Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27--11992721" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 12:27:24 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 02 Mar 2009 12:27:25 +0100 (CET) Subject: [DNSOP] RFC4641bis-00: start of a journey. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 11:27:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-27--11992721 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear Colleagues, I've just posted draft-ietf-dnsop-rfc4641bis-00.txt, it should appear in the repository real soon. What follows is non-technical, just some administration this version and how I will proceed. The document is essentially a copy of RFC4641 with the following changes (as taken from Appendix D): D.1. draft-ietf-dnsop-rfc4641-00 Version 0 was differs from RFC4641 in the following ways. o Status of this memo appropriate for I-D o TOC formatting differs. o Whitespaces, linebreaks, and pagebreaks may be slightly different because of xml2rfc generation. o References slightly reordered. o Applied the errata from http://www.rfc-editor.org/errata_search.php?rfc=4641 o Inserted trivial "IANA considertations" section. In other words it should not contain substantive changes in content as intended by the workinggroup for the original RFC4641. For a detailed diff see: http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/rfc/rfc4641.txt&url2=http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis-00.txt which is a diff between the RFC and the version I've just submitted. The reason why it took so long for this document to be submitted was that I wanted to wait for the IPR issues to be sorted out. This document definitely contained contributions from 3rd parties on which both Me, my previous employer, Miek, and his previous employer, could not make any copyright statements about. I have been working on a version 1 of this document which I plan to post before the document cut off and where some of the open issues will have straw-man text. With this version 00 in hand it should be fairly easy to use the IETF diff tools to track further changes. For the current list of open issues see: http://open.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ each open issue has its own file with a description and references. More as soon as I've published version 1, hopefully by the end of this week. --Olaf --Apple-Mail-27--11992721 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkmrwpwACgkQtN/ca3YJIocF4ACeJWCh0/m0W13rzD4FC8hFRCqd XrQAoOOZZezDxhQs6pW/61nsSVLTtBGz =Rg40 -----END PGP SIGNATURE----- --Apple-Mail-27--11992721-- From root@core3.amsl.com Mon Mar 2 03:30:01 2009 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AF02A28C20A; Mon, 2 Mar 2009 03:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090302113001.AF02A28C20A@core3.amsl.com> Date: Mon, 2 Mar 2009 03:30:01 -0800 (PST) Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 11:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Operational Practices Author(s) : O. Kolkman, M. Gieben Filename : draft-ietf-dnsop-rfc4641bis-00.txt Pages : 33 Date : 2009-03-02 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsop-rfc4641bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-02031602.I-D@ietf.org> --NextPart-- From richard.lamb@icann.org Wed Mar 4 00:57:32 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EC428C35B for ; Wed, 4 Mar 2009 00:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cZ16PqrIuKb for ; Wed, 4 Mar 2009 00:57:31 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id F197B28C355 for ; Wed, 4 Mar 2009 00:57:30 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 4 Mar 2009 00:57:59 -0800 From: Richard Lamb To: "Stephen.Morris@nominet.org.uk" , "dnsop@ietf.org" Date: Wed, 4 Mar 2009 00:58:01 -0800 Thread-Topic: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00 Thread-Index: AcmRG8YqnrqDYeijTtGac/OrQX7mwALimZew Message-ID: <05B243F724B2284986522B6ACD0504D789082168AA@EXVPMBX100-1.exc.icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 08:57:32 -0000 A very useful piece of work. Particularly the material on emergency key rol= lover. It took me some time to write the scripts to take into account TTL, = propagation delays, and various key compromise scenarios. The approach you= r work takes gives the implementer a clear framework. Wish I had your work= before. -Rick -----Original Message----- From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of S= tephen.Morris@nominet.org.uk Sent: Tuesday, February 17, 2009 10:21 AM To: dnsop@ietf.org Subject: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00 John Dickinson and Johan Ihren and I have just submitted=20 http://www.ietf.org/internet-drafts/draft-morris-dnsop-dnssec-key-timing-00= .txt The draft gives a rigorous description of timing considerations in DNSSEC=20 key rollovers. Stephen =20 > A new version of I-D, draft-morris-dnsop-dnssec-key-timing-00.txt=20 > has been successfuly submitted by Stephen Morris and posted to the=20 > IETF repository. >=20 > Filename: draft-morris-dnsop-dnssec-key-timing > Revision: 00 > Title: DNSSEC Key Timing Considerations > Creation_date: 2009-02-17 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > RFC 4641 gives a detailed overview of the operational considerations > involved in running a DNSSEC-secured zone, including key rollovers. > This document expands on the previous work, and discusses timing > considerations in greater depth. It explicitly identifies the > relationships between the various time parameters, and gives a > suggested algorithm for key rollover in a DNSSEC-secured zone. > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop From bortzmeyer@nic.fr Wed Mar 4 01:53:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003373A69FC for ; Wed, 4 Mar 2009 01:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=2.333, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48wHsHti2No1 for ; Wed, 4 Mar 2009 01:53:14 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 2E76E3A67AA for ; Wed, 4 Mar 2009 01:53:14 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0E76F1C0112; Wed, 4 Mar 2009 10:48:41 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 099D71C010F; Wed, 4 Mar 2009 10:48:41 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id F1FF6A1D95A; Wed, 4 Mar 2009 10:48:40 +0100 (CET) Date: Wed, 4 Mar 2009 10:48:40 +0100 From: Stephane Bortzmeyer To: Lars-Johan Liman Message-ID: <20090304094840.GB17233@nic.fr> References: <20090304010001.D285A3A68CF@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304010001.D285A3A68CF@core3.amsl.com> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 09:53:15 -0000 On Tue, Mar 03, 2009 at 05:00:01PM -0800, Internet-Drafts@ietf.org wrote a message of 52 lines which said: > Title : Top Level Domain Name Specification > Author(s) : L. Liman > Filename : draft-liman-tld-names-00.txt [What is the proper email address for discussions? Let's try dnsop.] > tldlabel = ALPHA *61(ldh) ld Why at least two characters? Why not: tldlabel = ALPHA *1(*61(ldh) ld) There is no *technical* reason to prevent one-letter TLDs (there can be layer-8 reasons but they are handled by section 3). From liman@autonomica.se Wed Mar 4 04:29:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6973A6BE7 for ; Wed, 4 Mar 2009 04:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiPucKYrtjjY for ; Wed, 4 Mar 2009 04:29:36 -0800 (PST) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C092E3A6BFF for ; Wed, 4 Mar 2009 04:29:33 -0800 (PST) Received: from home.liman.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n24CTxx4021717; Wed, 4 Mar 2009 13:29:59 +0100 (MET) Received: from zaptop.autonomica.net (zaptop.autonomica.net [192.71.80.71]) by home.liman.net (8.13.8/8.13.8) with ESMTP id n24CTww3018608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Mar 2009 13:29:59 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.1/8.14.1) with ESMTP id n24CTwh1001425; Wed, 4 Mar 2009 13:29:58 +0100 (CET) To: Stephane Bortzmeyer References: <20090304010001.D285A3A68CF@core3.amsl.com> <20090304094840.GB17233@nic.fr> From: Lars-Johan Liman Date: Wed, 04 Mar 2009 13:29:58 +0100 In-Reply-To: <20090304094840.GB17233@nic.fr> (Stephane Bortzmeyer's message of "Wed\, 4 Mar 2009 10\:48\:40 +0100") Message-ID: <22ocwh8o8p.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:29:37 -0000 bortzmeyer@nic.fr: > [What is the proper email address for discussions? Let's try dnsop.] [I had hoped to avoid pinpointing it to a specific working group just yet ... It's neither a typical protocol spec, nor a server operations issue, so it doesn't fit "naturally" in either of them.] >> tldlabel = ALPHA *61(ldh) ld > Why at least two characters? Why not: > tldlabel = ALPHA *1(*61(ldh) ld) > There is no *technical* reason to prevent one-letter TLDs (there can > be layer-8 reasons but they are handled by section 3). You may be quite right about that. It's one of the things that I want to have a discussion about. I started out with a somewhat conservative specification, to see where the discussion will take us. More voices? Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail/SIP/Jabber: liman@autonomica.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Autonomica AB, Stockholm ! http://www.autonomica.se/ #---------------------------------------------------------------------- From alexander.mayrhofer@nic.at Wed Mar 4 05:56:12 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7533A6C9F for ; Wed, 4 Mar 2009 05:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.78 X-Spam-Level: X-Spam-Status: No, score=-8.78 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtf7TS0gU8ef for ; Wed, 4 Mar 2009 05:56:11 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 04A4B3A6C80 for ; Wed, 4 Mar 2009 05:56:10 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Wed, 4 Mar 2009 14:56:36 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Mar 2009 14:56:35 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> In-Reply-To: <22ocwh8o8p.fsf@zaptop.autonomica.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] I-D Action:draft-liman-tld-names-00.txt Thread-Index: AcmcxP4DzLQBeaUiTg+bv7+XEyck5AAC/FtQ References: <20090304010001.D285A3A68CF@core3.amsl.com><20090304094840.GB17233@nic.fr> <22ocwh8o8p.fsf@zaptop.autonomica.net> From: "Alexander Mayrhofer" To: "Lars-Johan Liman" , "Stephane Bortzmeyer" X-XWALL-BCKS: auto Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 13:56:12 -0000 > You may be quite right about that. It's one of the things that I want > to have a discussion about. I started out with a somewhat conservative > specification, to see where the discussion will take us. >=20 > More voices? I would keep the ABNF to purely *technical* limits as well. Don't let the ABNF preclude any policy decisions. Alex From bortzmeyer@nic.fr Wed Mar 4 06:18:42 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ADA28C281 for ; Wed, 4 Mar 2009 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmsm5BESmX-O for ; Wed, 4 Mar 2009 06:18:41 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id E8CEA28C381 for ; Wed, 4 Mar 2009 06:18:29 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 43B271C0188; Wed, 4 Mar 2009 15:13:57 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 3E2DB1C0155; Wed, 4 Mar 2009 15:13:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 3C105A1D97E; Wed, 4 Mar 2009 15:13:57 +0100 (CET) Date: Wed, 4 Mar 2009 15:13:57 +0100 From: Stephane Bortzmeyer To: Alexander Mayrhofer Message-ID: <20090304141357.GA17627@nic.fr> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:18:42 -0000 On Wed, Mar 04, 2009 at 02:56:35PM +0100, Alexander Mayrhofer wrote a message of 10 lines which said: > I would keep the ABNF to purely *technical* limits as well. Don't let > the ABNF preclude any policy decisions. +1 But this criteria is easier written than applied. For instance, should the ABNF allow fully-numeric top-level domain names? There is no *technical* reason to ban them. With IPv4, RFC 1123 section 2.1 clearly says "The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System" so 1.2.3.112 is unambiguously the machine of IP address 1.2.3.112 even if the TLD ".112" is delegated. (With IPv6, it is even clearer since applications typically require some form of indication that it is an IP address, see RFC 3986 section 3.2.2). [In case you wonder, yes, I'm for allowing fully-numeric TLD, _in that I-D_, section 3 still being applicable.] From ajs@shinkuro.com Wed Mar 4 08:55:14 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2CC3A6B56 for ; Wed, 4 Mar 2009 08:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCRUu1C9xe3n for ; Wed, 4 Mar 2009 08:55:13 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 983B23A6AE5 for ; Wed, 4 Mar 2009 08:55:13 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5D7682FEA3F8 for ; Wed, 4 Mar 2009 16:55:41 +0000 (UTC) Date: Wed, 4 Mar 2009 11:55:39 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090304165539.GN6574@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304141357.GA17627@nic.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:55:14 -0000 On Wed, Mar 04, 2009 at 03:13:57PM +0100, Stephane Bortzmeyer wrote: > But this criteria is easier written than applied. For instance, should > the ABNF allow fully-numeric top-level domain names? There is no > *technical* reason to ban them. There's a strong technical reason to ban any numeric TLD name that could be interpreted as part of a dotted-quad, however, and for the sake of technical simplicity it might in fact be much easier just to ban them all instead. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Wed Mar 4 09:24:27 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23053A68AD for ; Wed, 4 Mar 2009 09:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgt7H+LdWWdT for ; Wed, 4 Mar 2009 09:24:27 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AAEA63A6A17 for ; Wed, 4 Mar 2009 09:24:25 -0800 (PST) Received: from [10.31.200.116] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n24HOo6u016816; Wed, 4 Mar 2009 12:24:50 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090304141357.GA17627@nic.fr> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> Date: Wed, 4 Mar 2009 12:24:46 -0500 To: Stephane Bortzmeyer From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: Alexander Mayrhofer , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 17:24:27 -0000 At 15:13 +0100 3/4/09, Stephane Bortzmeyer wrote: >But this criteria is easier written than applied. For instance, should >the ABNF allow fully-numeric top-level domain names? There is no >*technical* reason to ban them. There is one. I am not the best person to describe the entire problem but I'll give it a t= ry. When it come to IDNs there is a case of "BiDi" (bidirectional) characters. Some characters have encoded in them the=20 placement of the next character, to the right or=20 left. These characters are strong. Other=20 characters do not have this information, they are=20 weak. Numbers and punctuation are weak. Other symbols=20 (it's not accurate to call them letters) are=20 strong (not exclusively). Because you might mix=20 numbers and digits in a domain name (www.163.com)=20 the weak characters will inherit the directional=20 information of the other characters. =46or the raw data I learned this from, look at these links: http://stupid.domain.name/node/681 http://stupid.domain.name/node/682 http://stupid.domain.name/node/683 And the only confirmation I have that I'm "on to=20 something" is this in private correspondence with=20 the Patrik. I include his comments because I am=20 still not competent on this subject. At 1:55 +0100 12/2/08, Patrik F=E4ltstr=F6m wrote: #On 1 dec 2008, at 22.06, Edward Lewis wrote: # #> So, when pressed to explain this to someone, is this more or less accurat= e?: #> #> With IDNs and specifically bidirectional text (referring to left to right #> reading languages like Arabic), the direction in which the characters are #> to be rendered ("is this one to the right or the left of the previous") i= s #> sometimes stored in the data of the character itself. # # I would say "...is dependent on the directionality properties of the # character". # #> Characters with this data are "strong" and those without are "weak." # #"..with explicit directionality data are..." # #> Because of the special role of punctuation and=20 of digits, they are both weak. # # "...both weak which implies the order depends among other things on the # overall directionality of the text." # #> Because a dot and a digit are weak, there's no way to guarantee that #> ".1" will never be seen as "1." in a domain name. There is a way to #> guarantee it if you include directional aids, but this is apparently not #> done where domain names appear. # #Correct. >[In case you wonder, yes, I'm for allowing fully-numeric TLD, _in that >I-D_, section 3 still being applicable.] Curious - still? -- -=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-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. From peter@denic.de Wed Mar 4 13:19:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDFE28C20D for ; Wed, 4 Mar 2009 13:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tPZm7yL+G4D for ; Wed, 4 Mar 2009 13:19:36 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 2C1C528C188 for ; Wed, 4 Mar 2009 13:19:35 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LeyVW-0006BZ-Va; Wed, 04 Mar 2009 22:20:03 +0100 Received: from localhost by x27.adm.denic.de with local id 1LeySe-000512-Lx; Wed, 04 Mar 2009 22:17:04 +0100 Date: Wed, 4 Mar 2009 22:17:04 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20090304211704.GA18118@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Call for agenda items for San Francisco/IETF 74 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:19:37 -0000 Dear WG, the agenda for San Francisco gives us a 100 minute slot on Tuesday afternoon: Date: Tuesday, 25 March 2009 Time: 15:20 - 17:00 (UTC-8) //mmox, ancp, mext, speermint, rtgarea, keyprov, krb-wg Please let Rob and me know of any items you'd like to see on the agenda. Also, please note the cutoff dates listed at A non-authoritative excerpt is here: 2009-03-09, Mon, 24:00 UTC - Internet Draft final submission cut-off 2009-03-11, Wed, 24:00 UTC - Draft Working Group agendas due 2009-03-16, Mon, 24:00 UTC - Revised Working Group agendas due 2009-03-22- 2009-03-27 - IETF 74 You can find the minutes for the Minneapolis meeting (IETF 73) at . The audio recordings aren't yet available, but that's being worked on. -Peter From Mark_Andrews@isc.org Wed Mar 4 15:23:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB4328C3A2 for ; Wed, 4 Mar 2009 15:23:20 -0800 (PST) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5xhezuvApzy for ; Wed, 4 Mar 2009 15:23:19 -0800 (PST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 91D2028C33A for ; Wed, 4 Mar 2009 15:23:19 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 9EDDF11401F; Wed, 4 Mar 2009 23:23:36 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 11064E6074; Wed, 4 Mar 2009 23:23:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n24NNXuZ036757; Thu, 5 Mar 2009 10:23:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903042323.n24NNXuZ036757@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews In-reply-to: Your message of "Wed, 04 Mar 2009 11:55:39 CDT." <20090304165539.GN6574@shinkuro.com> Date: Thu, 05 Mar 2009 10:23:33 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:23:20 -0000 In message <20090304165539.GN6574@shinkuro.com>, Andrew Sullivan writes: > On Wed, Mar 04, 2009 at 03:13:57PM +0100, Stephane Bortzmeyer wrote: > > > But this criteria is easier written than applied. For instance, should > > the ABNF allow fully-numeric top-level domain names? There is no > > *technical* reason to ban them. > > There's a strong technical reason to ban any numeric TLD name that > could be interpreted as part of a dotted-quad, however, and for the > sake of technical simplicity it might in fact be much easier just to > ban them all instead. 3735928559 is also a IPv4 address. 222.11386607 is also a IPv4 address. 0xdeadbeef is also a IPv4 address. 0xde.0xadbeef is also a IPv4 address. 0xde.0xad.0xbeef is also a IPv4 address. 0xde.0xad.0xbe.0xef is also a IPv4 address. Banning tlds that start with a digit is the simplest most straight forward way to stop confusion. I know of no IPv4 address format that starts with a letter. IPv6 address presentation forms have colons in them so they are not going to collide with hostnames. Mark > A > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From bortzmeyer@nic.fr Fri Mar 6 00:07:26 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B7B3A6B09 for ; Fri, 6 Mar 2009 00:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xsnThV5oZPQ for ; Fri, 6 Mar 2009 00:07:20 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id F1F8D3A69DE for ; Fri, 6 Mar 2009 00:07:19 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 72CEB1C0126 for ; Fri, 6 Mar 2009 09:07:49 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 6EB731C011A for ; Fri, 6 Mar 2009 09:07:49 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 62F3DA1D97E for ; Fri, 6 Mar 2009 09:07:49 +0100 (CET) Date: Fri, 6 Mar 2009 09:07:49 +0100 From: Stephane Bortzmeyer To: IETF DNSOP WG Message-ID: <20090306080749.GB5034@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [DNSOP] Microsoft updates RFC 2606 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 08:07:26 -0000 I just discovered that Microsoft registered tempuri.com (and .org) and apparently promotes them for use in documentation and examples, ignoring RFC 2606. http://www.google.com/search?q="tempuri"+site%3Amicrosoft.com From bortzmeyer@nic.fr Fri Mar 6 02:01:17 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE143A6B12 for ; Fri, 6 Mar 2009 02:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.962 X-Spam-Level: X-Spam-Status: No, score=-4.962 tagged_above=-999 required=5 tests=[AWL=1.287, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb1IUBnd2kmG for ; Fri, 6 Mar 2009 02:01:17 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id D27963A693E for ; Fri, 6 Mar 2009 02:01:16 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 004491C018E; Fri, 6 Mar 2009 10:56:46 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id EF0571C0184; Fri, 6 Mar 2009 10:56:45 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id E23EEA1D95C; Fri, 6 Mar 2009 10:56:45 +0100 (CET) Date: Fri, 6 Mar 2009 10:56:45 +0100 From: Stephane Bortzmeyer To: Andrew Sullivan Message-ID: <20090306095645.GA19005@nic.fr> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304165539.GN6574@shinkuro.com> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 10:01:17 -0000 On Wed, Mar 04, 2009 at 11:55:39AM -0500, Andrew Sullivan wrote a message of 22 lines which said: > There's a strong technical reason to ban any numeric TLD name that > could be interpreted as part of a dotted-quad, They cannot be "interpreted as part of a dotted-quad" if everyone follows RFC 1123 section 2.1 "The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System". From jaap@bartok.nlnetlabs.nl Fri Mar 6 02:12:35 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EFD3A6A92 for ; Fri, 6 Mar 2009 02:12:35 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IrX+QkpTEKi for ; Fri, 6 Mar 2009 02:12:27 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 8C35C3A6826 for ; Fri, 6 Mar 2009 02:12:27 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n26ACqGi077585; Fri, 6 Mar 2009 11:12:52 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200903061012.n26ACqGi077585@bartok.nlnetlabs.nl> To: Stephane Bortzmeyer In-reply-to: Your message of Fri, 06 Mar 2009 09:07:49 +0100. <20090306080749.GB5034@nic.fr> Date: Fri, 06 Mar 2009 11:12:52 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Fri, 06 Mar 2009 11:12:52 +0100 (CET) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Microsoft updates RFC 2606 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 10:12:35 -0000 I just discovered that Microsoft registered tempuri.com (and .org) and apparently promotes them for use in documentation and examples, ignoring RFC 2606. Actually, if you read the text at that link, it is for using in experimental XML namespaces. jaap From root@core3.amsl.com Fri Mar 6 06:15:01 2009 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4BA2F3A6B4B; Fri, 6 Mar 2009 06:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306141501.4BA2F3A6B4B@core3.amsl.com> Date: Fri, 6 Mar 2009 06:15:01 -0800 (PST) Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : O. Kolkman, M. Gieben Filename : draft-ietf-dnsop-rfc4641bis-01.txt Pages : 38 Date : 2009-03-06 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsop-rfc4641bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06060703.I-D@ietf.org> --NextPart-- From Mark_Andrews@isc.org Fri Mar 6 06:32:42 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4BD3A6C52 for ; Fri, 6 Mar 2009 06:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdKJVA9iNnMA for ; Fri, 6 Mar 2009 06:32:41 -0800 (PST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id F41953A6970 for ; Fri, 6 Mar 2009 06:32:40 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id CD91911402C; Fri, 6 Mar 2009 14:33:00 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 05247E6074; Fri, 6 Mar 2009 14:32:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n26EWvuF009401; Sat, 7 Mar 2009 01:32:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903061432.n26EWvuF009401@drugs.dv.isc.org> To: Stephane Bortzmeyer From: Mark Andrews In-reply-to: Your message of "Fri, 06 Mar 2009 10:56:45 BST." <20090306095645.GA19005@nic.fr> Date: Sat, 07 Mar 2009 01:32:57 +1100 Sender: Mark_Andrews@isc.org Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:32:42 -0000 In message <20090306095645.GA19005@nic.fr>, Stephane Bortzmeyer writes: > On Wed, Mar 04, 2009 at 11:55:39AM -0500, > Andrew Sullivan wrote > a message of 22 lines which said: > > > There's a strong technical reason to ban any numeric TLD name that > > could be interpreted as part of a dotted-quad, > > They cannot be "interpreted as part of a dotted-quad" if everyone > follows RFC 1123 section 2.1 "The host SHOULD check the string > syntactically for a dotted-decimal number before looking it up in the > Domain Name System". If I put this record into the DNS "1.2.3.4. A 4.3.2.1" and email to user@1.2.3.4. Where does the email go? Next I telnet to 1.2.3.4 port 25. Where does that connection go? If 1.2.3.4 is a legal hostname / mail domain then the first will go to 4.3.2.1 port 25 and the second to 1.2.3.4 port 25. To send email to a IP address I need to use "user@[1.2.3.4]". The MTA knows 1.2.3.4 is a hostname not a IP address. Put 1.2.3.4 into the rdata of a MX/SRV record. Similar problem at the client knows these are name and not addresses. Mark > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From ajs@shinkuro.com Fri Mar 6 11:08:27 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913063A6C30 for ; Fri, 6 Mar 2009 11:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v7QRuhkmLUJ for ; Fri, 6 Mar 2009 11:08:26 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CCC0B3A6A07 for ; Fri, 6 Mar 2009 11:08:26 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2A2D32FEA556 for ; Fri, 6 Mar 2009 19:08:57 +0000 (UTC) Date: Fri, 6 Mar 2009 14:08:55 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090306190855.GL12711@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090306095645.GA19005@nic.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:08:27 -0000 On Fri, Mar 06, 2009 at 10:56:45AM +0100, Stephane Bortzmeyer wrote: > They cannot be "interpreted as part of a dotted-quad" if everyone > follows RFC 1123 section 2.1 "The host SHOULD check the string > syntactically for a dotted-decimal number before looking it up in the > Domain Name System". Funny you should say that, because RFC 1123 section 2.1 _also_ says, "However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic." Therefore, I think appealing to the RFC 1123 rules for this case is going to be tricky. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Fri Mar 6 11:38:13 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425EC3A6B37 for ; Fri, 6 Mar 2009 11:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zj2oAikDAZf for ; Fri, 6 Mar 2009 11:38:12 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6248C3A6AD6 for ; Fri, 6 Mar 2009 11:38:12 -0800 (PST) Received: from [10.31.200.116] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n26JceVY058243; Fri, 6 Mar 2009 14:38:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090306190855.GL12711@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> Date: Fri, 6 Mar 2009 14:38:37 -0500 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:38:13 -0000 At 14:08 -0500 3/6/09, someone wrote: >...I think appealing to the RFC 1123 rules for this case is going to >be tricky. Remember that RFC 1123 was written in a historical epoch much different than today. No IDNs. No URLs. No thought of domain names in newspapers. The BiDi issue will pretty much prevent us from seeing a TLD beginning or ending with a digit in the global public Internet root zone. Even if the whole issue is too new to be in an RFC (IETF's IDNABIS WG might get around to one). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much. From ajs@shinkuro.com Fri Mar 6 12:13:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6AA3A695C for ; Fri, 6 Mar 2009 12:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kai7gZg+wVn1 for ; Fri, 6 Mar 2009 12:13:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1A8983A697B for ; Fri, 6 Mar 2009 12:13:20 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B831D2FEA556 for ; Fri, 6 Mar 2009 20:13:49 +0000 (UTC) Date: Fri, 6 Mar 2009 15:13:47 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090306201347.GO12711@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:13:20 -0000 On Fri, Mar 06, 2009 at 02:38:37PM -0500, Edward Lewis wrote: > Remember that RFC 1123 was written in a historical epoch much different > than today. No IDNs. No URLs. No thought of domain names in > newspapers. But depending on whether you think the text I quoted is normative, 1123 may actually forbid those IDNs at the top level. Which would be a bad thing, I think. > The BiDi issue will pretty much prevent us from seeing a TLD beginning or > ending with a digit in the global public Internet root zone. Even if the > whole issue is too new to be in an RFC (IETF's IDNABIS WG might get > around to one). Surely not. The BiDi issue may prevent anyone from seeing a U-label beginning or ending with a digit from being "added" to the root. What actually gets added to the root zone, however, is an A-label. It makes no difference whether that A-label begins or ends with a digit (it won't begin, I predict, but I'm not sure whether it might end with one), since A-labels are always ASCII. Or are you saying that display issues coming from ASCII-only labels in a BiDi display context need to govern the contents of zone files. If so, I think that really really needs to get raised in idnabis soon. That's not my understanding of the issue so far. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Fri Mar 6 12:54:40 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4583A6870 for ; Fri, 6 Mar 2009 12:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHgcPLkhG+Ri for ; Fri, 6 Mar 2009 12:54:40 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DF6CF3A676A for ; Fri, 6 Mar 2009 12:54:39 -0800 (PST) Received: from [10.31.200.116] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n26Kt5xK001298; Fri, 6 Mar 2009 15:55:05 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090306201347.GO12711@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> Date: Fri, 6 Mar 2009 15:54:58 -0500 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:54:41 -0000 At 15:13 -0500 3/6/09, Andrew Sullivan wrote: >But depending on whether you think the text I quoted is normative, >1123 may actually forbid those IDNs at the top level. Which would be >a bad thing, I think. I'm not sure what...a bad thing would be forbidding IDNs or is a bad thing removing the prohibition on IDNs...anyway. I think that there's going to be some room to question the old texts due to new requirements. While we can't always upend the installed base because we want to expand the capabilities, sometimes it's the way the rules were written that is the issue. >Or are you saying that display issues coming from ASCII-only labels in >a BiDi display context need to govern the contents of zone files. If >so, I think that really really needs to get raised in idnabis soon. >That's not my understanding of the issue so far. I"ll preface my response by saying - I'm not all that confident in my knowledge of IDNs and the BiDi issue. But when I talked with some folks around the ICANN circus, there was conventional wisdom that there would be no admission of a delegation beginning or ending with a digit to the root zone. This bar was in place because of the BiDi issues as I understand from Patrik Faltstrom's blog. And, from what I have heard, I believe "display issues" is at the heart of the problem. I'm sure Patrik is active in the IDNABIS WG. So if it is an issue, he'd have spoken about it. Still, seriously, all this aside, I doubt we will ever want "manpages.5" as a domain name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much. From ajs@shinkuro.com Fri Mar 6 13:10:45 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176B03A68AD for ; Fri, 6 Mar 2009 13:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Ds0+Qp81Fp for ; Fri, 6 Mar 2009 13:10:44 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3FAD23A6869 for ; Fri, 6 Mar 2009 13:10:44 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 431D82FEA556 for ; Fri, 6 Mar 2009 21:11:14 +0000 (UTC) Date: Fri, 6 Mar 2009 16:11:11 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090306211111.GP12711@shinkuro.com> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 21:10:45 -0000 On Fri, Mar 06, 2009 at 03:54:58PM -0500, Edward Lewis wrote: > knowledge of IDNs and the BiDi issue. But when I talked with some folks > around the ICANN circus, there was conventional wisdom that there would > be no admission of a delegation beginning or ending with a digit to the > root zone. This bar was in place because of the BiDi issues as I > understand from Patrik Faltstrom's blog. > > And, from what I have heard, I believe "display issues" is at the heart > of the problem. Ok, so the "no beginning or ending digit" rule is a rule about U-labels, and not necessarily about A-labels. So the outstanding question, relevant to the draft at hand, is whether the issue is important for A-labels as well. Since this has been a topic of some importance in IDNAbis, I'll ask the people over there about it. Patrik is not the only person in that community who's on top of this issue. [Aside: while I'm on the topic of IDNAbis, I've recently again been reminded that it'd be really, really good if people with DNS clue would have a look at that work to see if there's anything problematic.] > Still, seriously, all this aside, I doubt we will ever want "manpages.5" > as a domain name. But I have no difficulty imagining someone with more money than sense wanting .666 as a TLD. And with the latest ICANN policies, they'd have a stronger argument than they once did. The question is whether there are important technical reasons to say no. "666" could never appear as part of an IPv4 address, after all. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jaap@bartok.nlnetlabs.nl Fri Mar 6 15:00:16 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C0228C0D7 for ; Fri, 6 Mar 2009 15:00:16 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56EPi67oG3dI for ; Fri, 6 Mar 2009 15:00:16 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id EE9763A69BF for ; Fri, 6 Mar 2009 15:00:15 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n26N0fUF091084 for ; Sat, 7 Mar 2009 00:00:41 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200903062300.n26N0fUF091084@bartok.nlnetlabs.nl> To: dnsop@ietf.org In-reply-to: Your message of Fri, 06 Mar 2009 16:11:11 -0500. <20090306211111.GP12711@shinkuro.com> Date: Sat, 07 Mar 2009 00:00:41 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Sat, 07 Mar 2009 00:00:41 +0100 (CET) Subject: [DNSOP] numeric labels X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 23:00:16 -0000 I haven't read the draft yet, but the discussion whether numeric labels are allowed seems to get slightly out of hand. Anybody can use them and apparently people are. That is easily proved but running something like: for i in `seq 1 1 1000`; do echo $i; dig +short $i.com; done and replace .com with different TLDs such as .info, .biz, .pro, .cn, .nl etc. as well. (Variations in the boundaries is also advised so you can stumble on 4711 and similar trademarks). Whatever the scriptures are saying or how they can be interpreted, I haven't seen seen the network crashing down due to this practice. That using multiple numeric domains can backfire and that if you open a web-shop at the host named 127.0.0.1 might not result in a stellar sized customer base is something completely different. You just get what you ask for. jaap From Mark_Andrews@isc.org Fri Mar 6 15:42:47 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDACD3A681C for ; Fri, 6 Mar 2009 15:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJI2BdcRsWBe for ; Fri, 6 Mar 2009 15:42:47 -0800 (PST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id C60953A69C7 for ; Fri, 6 Mar 2009 15:42:46 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id CC82B114021; Fri, 6 Mar 2009 23:43:01 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 26C53E6072; Fri, 6 Mar 2009 23:43:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n26Ngv6F014648; Sat, 7 Mar 2009 10:42:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903062342.n26Ngv6F014648@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews In-reply-to: Your message of "Fri, 06 Mar 2009 16:11:11 CDT." <20090306211111.GP12711@shinkuro.com> Date: Sat, 07 Mar 2009 10:42:57 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 23:42:47 -0000 In message <20090306211111.GP12711@shinkuro.com>, Andrew Sullivan writes: > On Fri, Mar 06, 2009 at 03:54:58PM -0500, Edward Lewis wrote: > > > knowledge of IDNs and the BiDi issue. But when I talked with some folks > > around the ICANN circus, there was conventional wisdom that there would > > be no admission of a delegation beginning or ending with a digit to the > > root zone. This bar was in place because of the BiDi issues as I > > understand from Patrik Faltstrom's blog. > > > > And, from what I have heard, I believe "display issues" is at the heart > > of the problem. > > Ok, so the "no beginning or ending digit" rule is a rule about > U-labels, and not necessarily about A-labels. So the outstanding > question, relevant to the draft at hand, is whether the issue is > important for A-labels as well. > > Since this has been a topic of some importance in IDNAbis, I'll ask > the people over there about it. Patrik is not the only person in that > community who's on top of this issue. > > [Aside: while I'm on the topic of IDNAbis, I've recently again been > reminded that it'd be really, really good if people with DNS clue > would have a look at that work to see if there's anything > problematic.] > > > Still, seriously, all this aside, I doubt we will ever want "manpages.5" > > as a domain name. > > But I have no difficulty imagining someone with more money than sense > wanting .666 as a TLD. And with the latest ICANN policies, they'd have > a stronger argument than they once did. The question is whether there > are important technical reasons to say no. "666" could never appear > as part of an IPv4 address, after all. 1.666 is a valid IP address. drugs:9.7.x 10:41 {322} % telnet 1.666 Trying 1.0.2.154... ^C drugs:9.7.x 10:42 {323} % > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From sm@resistor.net Fri Mar 6 23:02:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1223C3A6A8E for ; Fri, 6 Mar 2009 23:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OycSGcNjoLfq for ; Fri, 6 Mar 2009 23:02:01 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id C13493A6963 for ; Fri, 6 Mar 2009 23:02:01 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n2772IXj019420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 23:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1236409349; x=1236495749; bh=ql8+CRMpZiehF0OayB23ap9CEeIo8FwUvLeofDrKVcQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nFBlJpg3yVwW2qImP4CCFkh7Rrq6x6ygUY5kS+ovC7jBY6w/ET2w9H1m1sJ3MgcKq 2W/NZHja+xTDHpoD7HnM9zwfYWi1MWl7DqpBE5fRUtQFvF4GvnhD0Zh9J9tBQCSn40 5R8jKJXLz20mE1DIiK5cnInjTcxWaalCgpq+xM98= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Hsioi4ltWTeuhOuqmidEKAcShnaudTpz5y73KZE3+b8RwdjfivVlwsi/I9FhxGpL5 Ln3eYf0MIBuIXkT+ipHFfiBsi7krPnH4OCqj+w4dvDvE38rslltvwAtrZbUnOq+xTgu MyEJs+vKFU9AvH91esvWBK0cXZmqkZEJGzgYmf8= Message-Id: <6.2.5.6.2.20090306215832.02cd2838@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Mar 2009 22:58:58 -0800 To: Lars-Johan Liman From: SM In-Reply-To: <20090304010001.D285A3A68CF@core3.amsl.com> References: <20090304010001.D285A3A68CF@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: [DNSOP] draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 07:02:03 -0000 The topic discussed in draft-liman-tld-names-00 has two angles, the application angle and the DNS angle. The "requirements" can be different depending on which angle we are looking at. From Section 11 of RFC 2181: "The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record." "Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment." "Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data." The title of the document is "Top Level Domain Name Specification". If it is about gTLDs, some may see this as a matter for some other organization instead of the IETF. Section 4 of the draft requests IANA to change its registration process to use the specification. Is the registration process set by the IETF or an other organization? There are some clarifications about the syntax of an Internet host name in Section 2 of RFC 1123. The "Discussion" part of that section mentions: "However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic." According to Section 2 of draft-liman-tld-names-00, the top level domain label can be numeric only. This can lead to confusion if we cannot determine whether the string is a FQDN or an IP address. From Section 2.1 of RFC 1912 (Informational): "You should also be careful to not have addresses which are valid alternate syntaxes to the inet_ntoa() library call. For example 0xe is a valid name, but if you were to type "telnet 0xe", it would try to connect to IP address 0.0.0.14. It is also rumored that there exists some broken inet_ntoa() routines that treat an address like x400 as an IP address." The word "whether" is not spelled correctly in Section of the draft. There is ongoing work in the IDNAbis Working Group on IDNA. draft-ietf-idnabis-protocol-10 proposes to obsolete RFC 3490. Regards, -sm From olaf@nlnetlabs.nl Sat Mar 7 01:29:30 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15A03A698A for ; Sat, 7 Mar 2009 01:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ve1NKFywKk6 for ; Sat, 7 Mar 2009 01:29:29 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 8934D3A6905 for ; Sat, 7 Mar 2009 01:29:29 -0800 (PST) Received: from [192.168.178.24] (a82-95-132-144.adsl.xs4all.nl [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n279TufB065037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Mar 2009 10:29:56 +0100 (CET) (envelope-from olaf@nlnetlabs.nl) Message-Id: From: Olaf Kolkman To: dnsop@ietf.org Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16-412958539" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 10:29:56 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [213.154.224.1]); Sat, 07 Mar 2009 10:29:57 +0100 (CET) Subject: [DNSOP] RFC4641bis road trip: first stop X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 09:29:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16-412958539 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Lectori Salutem, draft-ietf-dnsop-rfc4641bis-01 has just been posted. I realize that this is not according to the rule to not submit 01 drafts shortly after a version 00 has been submitted and would understand if it would therefore not be able to feature the agenda. While draft-ietf-dnsop-rfc4641bis-00 is RFC4641 backported to XML with the errata fixed and some nits corrected this version contains some substantive material currently this is only strawman text intended to get progress on the issues currently addressed; not all open issues are addressed yet. For those who are familiar with the RFC4641 material I suggest that you look at appendix D.2 of the document that gives a summary of the changes and use the diff tool to assess where chances have been made. In other words use http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-00.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-01.txt or http://tinyurl.com/cm4qw2 I would like to ask careful review of the new recommendations in section 3, specifically the key size recommendations. As far as progressing this document I would like to close issues one by one and hope that after they are closed we can be strong enough not to revisit them. I will try to make an effort to high light certain arguments in the issue lists. Using SVN is a bit of an experiment. The issue list can be found at: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ Kind regards, --Olaf Kolkman --Apple-Mail-16-412958539 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkmyPpQACgkQtN/ca3YJIoedjACfY0v1OkI5VgExZMcXNqO7iXGl 38YAn3QYnF3tocY+th0a9ah8StYrCDLW =WmfR -----END PGP SIGNATURE----- --Apple-Mail-16-412958539-- From patrik@frobbit.se Sat Mar 7 03:07:04 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750483A6A6E for ; Sat, 7 Mar 2009 03:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4GfJAkyBBXf for ; Sat, 7 Mar 2009 03:07:03 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 67F023A69FC for ; Sat, 7 Mar 2009 03:07:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 06E9E3FB82CF; Sat, 7 Mar 2009 12:07:34 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFyub8qA1jeV; Sat, 7 Mar 2009 12:07:33 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 86D3F3FB82C4; Sat, 7 Mar 2009 12:07:33 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Edward Lewis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 12:07:01 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 11:07:04 -0000 On 6 mar 2009, at 21.54, Edward Lewis wrote: > And, from what I have heard, I believe "display issues" is at the > heart of the problem. > > I'm sure Patrik is active in the IDNABIS WG. So if it is an issue, > he'd have spoken about it. Yes, active there, following this list. > Still, seriously, all this aside, I doubt we will ever want > "manpages.5" as a domain name. I think regarding digits in TLDs (or rather, non-letters), this is the right time when one definitely should have the basic rule to not "add something until it breaks", but instead, "only add things we do know will not create any harm". And I think within those basic rules, we should just say no to digits in TLDs. Anywhere. Or rather, every character in a U-label in a TLD have to have an explicit directionality. I think it is time to not have a general rule "lets add something if not proven that adding will create harm", but instead "lets add something only if proven that it absolutely not does create any harm", and then have the people that want certain dangerous characters in there explain why it is safe. Patrik From bmanning@karoshi.com Sat Mar 7 05:55:46 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E8D3A6B4E for ; Sat, 7 Mar 2009 05:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=2.032, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQVJyGd+ulTQ for ; Sat, 7 Mar 2009 05:55:45 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 8D67B3A6B4C for ; Sat, 7 Mar 2009 05:55:45 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n27DuEff013166; Sat, 7 Mar 2009 13:56:15 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n27DuCF0013165; Sat, 7 Mar 2009 13:56:12 GMT Date: Sat, 7 Mar 2009 13:56:12 +0000 From: bmanning@vacation.karoshi.com To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20090307135612.GA13146@vacation.karoshi.com.> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 13:55:46 -0000 does this mean my chances for ^B. are nil? :) --bill On Sat, Mar 07, 2009 at 12:07:01PM +0100, Patrik Fdltstrvm wrote: > On 6 mar 2009, at 21.54, Edward Lewis wrote: > > >And, from what I have heard, I believe "display issues" is at the > >heart of the problem. > > > >I'm sure Patrik is active in the IDNABIS WG. So if it is an issue, > >he'd have spoken about it. > > Yes, active there, following this list. > > >Still, seriously, all this aside, I doubt we will ever want > >"manpages.5" as a domain name. > > I think regarding digits in TLDs (or rather, non-letters), this is the > right time when one definitely should have the basic rule to not "add > something until it breaks", but instead, "only add things we do know > will not create any harm". And I think within those basic rules, we > should just say no to digits in TLDs. Anywhere. Or rather, every > character in a U-label in a TLD have to have an explicit directionality. > > I think it is time to not have a general rule "lets add something if > not proven that adding will create harm", but instead "lets add > something only if proven that it absolutely not does create any harm", > and then have the people that want certain dangerous characters in > there explain why it is safe. > > Patrik > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From patrik@frobbit.se Sat Mar 7 06:13:16 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B053A6A8B for ; Sat, 7 Mar 2009 06:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TldHsrJL-akc for ; Sat, 7 Mar 2009 06:13:16 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id C75223A6885 for ; Sat, 7 Mar 2009 06:13:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BB39B3FBE8CC; Sat, 7 Mar 2009 15:13:46 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcYeuU+wk4DA; Sat, 7 Mar 2009 15:13:46 +0100 (CET) Received: from [192.168.1.46] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 68B5C3FBE8C1; Sat, 7 Mar 2009 15:13:45 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090307135612.GA13146@vacation.karoshi.com.> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-429986691" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 15:13:44 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <20090307135612.GA13146@vacation.karoshi.com.> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:13:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9-429986691 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 7 mar 2009, at 14.56, bmanning@vacation.karoshi.com wrote: > does this mean my chances for ^B. are nil? :) Go for it! But I think foo^H^H^Hbar is more interesting as a label. Maybe with a ^G in there as well. Patrik > > --bill > > > On Sat, Mar 07, 2009 at 12:07:01PM +0100, Patrik Fdltstrvm wrote: >> On 6 mar 2009, at 21.54, Edward Lewis wrote: >> >>> And, from what I have heard, I believe "display issues" is at the >>> heart of the problem. >>> >>> I'm sure Patrik is active in the IDNABIS WG. So if it is an issue, >>> he'd have spoken about it. >> >> Yes, active there, following this list. >> >>> Still, seriously, all this aside, I doubt we will ever want >>> "manpages.5" as a domain name. >> >> I think regarding digits in TLDs (or rather, non-letters), this is >> the >> right time when one definitely should have the basic rule to not "add >> something until it breaks", but instead, "only add things we do know >> will not create any harm". And I think within those basic rules, we >> should just say no to digits in TLDs. Anywhere. Or rather, every >> character in a U-label in a TLD have to have an explicit >> directionality. >> >> I think it is time to not have a general rule "lets add something if >> not proven that adding will create harm", but instead "lets add >> something only if proven that it absolutely not does create any >> harm", >> and then have the people that want certain dangerous characters in >> there explain why it is safe. >> >> Patrik >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > --Apple-Mail-9-429986691 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJsoEYrMabGguI180RAuHrAJ48zOi2MxzVk7GFcWUuO1a/LLkr9ACfcim0 2nP1uAX+//dueIAPwsy6Z6Q= =kSAu -----END PGP SIGNATURE----- --Apple-Mail-9-429986691-- From bmanning@karoshi.com Sat Mar 7 06:31:26 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CCC28C13C for ; Sat, 7 Mar 2009 06:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmUnBXiPa9jU for ; Sat, 7 Mar 2009 06:31:25 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 2EF0628C14A for ; Sat, 7 Mar 2009 06:31:24 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n27EVrff013360; Sat, 7 Mar 2009 14:31:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n27EVeCH013359; Sat, 7 Mar 2009 14:31:40 GMT Date: Sat, 7 Mar 2009 14:31:40 +0000 From: bmanning@vacation.karoshi.com To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20090307143140.GA13276@vacation.karoshi.com.> References: <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <20090307135612.GA13146@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Cc: Andrew Sullivan , bmanning@vacation.karoshi.com, Edward Lewis , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:31:26 -0000 na... the ^B. is for the visually impared. the DNS can talk! (and it does meet your "explict directionality" concern.) actually, I have a fundamental disagreement w/ your logic. I think that your general rule of "only add if proven to create no harm" or infering "dangerous" - are on the slippery slope of stifling inovation. IDN's by their very nature are proven to create harm... yet we are doing them :) i think the better rule is, add something if it creates value. --bill On Sat, Mar 07, 2009 at 03:13:44PM +0100, Patrik Fdltstrvm wrote: > On 7 mar 2009, at 14.56, bmanning@vacation.karoshi.com wrote: > > >does this mean my chances for ^B. are nil? :) > > Go for it! > > But I think foo^H^H^Hbar is more interesting as a label. Maybe with a > ^G in there as well. > > Patrik > > > > >--bill > > > >>I think it is time to not have a general rule "lets add something if > >>not proven that adding will create harm", but instead "lets add > >>something only if proven that it absolutely not does create any > >>harm", > >>and then have the people that want certain dangerous characters in > >>there explain why it is safe. > >> > >> Patrik > >> > >>_______________________________________________ > >>DNSOP mailing list > >>DNSOP@ietf.org > >>https://www.ietf.org/mailman/listinfo/dnsop > > > From patrik@frobbit.se Sat Mar 7 06:38:30 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622A128C14A for ; Sat, 7 Mar 2009 06:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb0GshR-cFHr for ; Sat, 7 Mar 2009 06:38:29 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 757BD28C13C for ; Sat, 7 Mar 2009 06:38:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 42D043FBF84C; Sat, 7 Mar 2009 15:39:00 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxhKNzyyBTzq; Sat, 7 Mar 2009 15:39:00 +0100 (CET) Received: from [192.168.1.46] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 8CD293FBF83E; Sat, 7 Mar 2009 15:38:59 +0100 (CET) Message-Id: <3CFD239E-1139-4484-B49E-B2FD10BC6051@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090307143140.GA13276@vacation.karoshi.com.> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-13-431500750" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 15:38:58 +0100 References: <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <20090307135612.GA13146@vacation.karoshi.com.> <20090307143140.GA13276@vacation.karoshi.com.> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:38:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-13-431500750 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 7 mar 2009, at 15.31, bmanning@vacation.karoshi.com wrote: > na... the ^B. is for the visually impared. the DNS can talk! > (and it does meet your "explict directionality" concern.) If you with ^B talk about U+0002, then it does not fulfil the explicit directionality requirements as it is BN, Boundary_Neutral. Patrik --Apple-Mail-13-431500750 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJsocCrMabGguI180RAvXnAKCD6guJsST/KrlXQDWcS0BwZA4XIgCeJu1B 0cBHeoDsK7UreX6O9lGrV3U= =oNXF -----END PGP SIGNATURE----- --Apple-Mail-13-431500750-- From ajs@shinkuro.com Sat Mar 7 07:01:01 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B1E3A67FC for ; Sat, 7 Mar 2009 07:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=1.421, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSLLJRodUKEB for ; Sat, 7 Mar 2009 07:01:00 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A30963A6784 for ; Sat, 7 Mar 2009 07:01:00 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C932A2FEA556 for ; Sat, 7 Mar 2009 15:01:31 +0000 (UTC) Date: Sat, 7 Mar 2009 10:01:30 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090307150129.GC15014@shinkuro.com> References: <20090304010001.D285A3A68CF@core3.amsl.com> <6.2.5.6.2.20090306215832.02cd2838@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20090306215832.02cd2838@resistor.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 15:01:01 -0000 On Fri, Mar 06, 2009 at 10:58:58PM -0800, SM wrote: > The title of the document is "Top Level Domain Name Specification". If > it is about gTLDs, some may see this as a matter for some other > organization instead of the IETF. Section 4 of the draft requests IANA > to change its registration process to use the specification. Is the > registration process set by the IETF or an other organization? I'm not sure I understand the worry here: the document reads perfectly clearly, to my eyes, that other organizations may have something to say about actual TLDs; the draft is only about the _technical_ specification of what may be in the TLD. > According to Section 2 of draft-liman-tld-names-00, the top level domain > label can be numeric only. No: 'and it MUST start with an ASCII "letter"'. Therefore, it can't be numeric only. In another thread I've been playing devil's advocate, attempting to see if there is any argument for weakening that position. So far, none, I'm delighted to say. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From drc@virtualized.org Sat Mar 7 07:24:44 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADABE3A682F for ; Sat, 7 Mar 2009 07:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6gyyRrru22b for ; Sat, 7 Mar 2009 07:24:44 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 149723A6784 for ; Sat, 7 Mar 2009 07:24:44 -0800 (PST) Received: from [10.0.1.6] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 5996C4A55EE; Sat, 7 Mar 2009 07:25:14 -0800 (PST) Message-Id: From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 05:25:12 -1000 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 15:24:44 -0000 Patrik, On Mar 7, 2009, at 1:07 AM, Patrik F=E4ltstr=F6m wrote: > I think it is time to not have a general rule "lets add something if =20= > not proven that adding will create harm", but instead "lets add =20 > something only if proven that it absolutely not does create any =20 > harm", and then have the people that want certain dangerous =20 > characters in there explain why it is safe. Define "harm". Regards, -drc From patrik@frobbit.se Sat Mar 7 07:32:33 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677A73A68CB for ; Sat, 7 Mar 2009 07:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Q5CTgCQOZc for ; Sat, 7 Mar 2009 07:32:32 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 73EDA3A6784 for ; Sat, 7 Mar 2009 07:32:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4DC763FC1A7A; Sat, 7 Mar 2009 16:33:03 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZC3qZhhOL6n; Sat, 7 Mar 2009 16:33:03 +0100 (CET) Received: from [192.168.1.46] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 9176E3FC1A6D; Sat, 7 Mar 2009 16:33:02 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-14-434743888" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 16:33:01 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 15:32:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-14-434743888 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 7 mar 2009, at 16.25, David Conrad wrote: > On Mar 7, 2009, at 1:07 AM, Patrik F=E4ltstr=F6m wrote: >> I think it is time to not have a general rule "lets add something =20 >> if not proven that adding will create harm", but instead "lets add =20= >> something only if proven that it absolutely not does create any =20 >> harm", and then have the people that want certain dangerous =20 >> characters in there explain why it is safe. > > Define "harm". I want it the other way around. I want someone to define "no harm". Examples might be things like inability for the owners of 2nd level =20 domains to enter the domain name they registered in browsers, problems =20= to use the domain name (including the TLD) in text, or whatever. I.e. =20= it to some degree have to do with what policy you have for =20 registrations in the 2nd level domain (for rendering purposes for =20 example). On top of this, I would like to have a situation where if someone =20 complains after you got your domain, it is your fault, not a problem =20 for an evaluation/assignment committee that did some evaluation (or =20 not). If you want a TLD, you tell me that you will not create any harm. You =20= do, you get the domain, things go poof, then you did not do your =20 homework beforehand. Patrik --Apple-Mail-14-434743888 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJspOtrMabGguI180RAhtgAJ4zEHGDhjqkfFaDwq9BWyHMna/AxgCfRYvI unC+kYQARHOzwP6h+PklrYA= =YXsi -----END PGP SIGNATURE----- --Apple-Mail-14-434743888-- From patrik@frobbit.se Sat Mar 7 07:35:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7043A6841 for ; Sat, 7 Mar 2009 07:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJhp53puIlFv for ; Sat, 7 Mar 2009 07:35:20 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id CB0903A67A1 for ; Sat, 7 Mar 2009 07:35:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 07D5B3FC1B98; Sat, 7 Mar 2009 16:35:51 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdM1mqcgfV2r; Sat, 7 Mar 2009 16:35:50 +0100 (CET) Received: from [192.168.1.46] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 095D93FC1B82; Sat, 7 Mar 2009 16:35:49 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15-434911432" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 16:35:49 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 15:35:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15-434911432 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 7 mar 2009, at 16.25, David Conrad wrote: > Define "harm". Here is a link to one of the blog pages of mine that show in a filesystem what I think is "harm" if we allow mix of codepoints etc that give same result(s) for domain names. http://stupid.domain.name/node/681 I claim that is "harm". Patrik --Apple-Mail-15-434911432 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD4DBQFJspRVrMabGguI180RAgjcAJjtgY4DvJbJxLUvz9d89Bf21imPAJ9qrZUw PBJuPBmYGwnuiNzfn9XFkQ== =4j9A -----END PGP SIGNATURE----- --Apple-Mail-15-434911432-- From jaap@bartok.nlnetlabs.nl Sat Mar 7 08:28:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A983A6842 for ; Sat, 7 Mar 2009 08:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo+pZ0OulmZb for ; Sat, 7 Mar 2009 08:28:36 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 440533A680F for ; Sat, 7 Mar 2009 08:28:33 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n27GSxrT053728; Sat, 7 Mar 2009 17:28:59 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200903071628.n27GSxrT053728@bartok.nlnetlabs.nl> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-reply-to: Your message of Sat, 07 Mar 2009 15:13:44 +0100. Date: Sat, 07 Mar 2009 17:28:59 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Sat, 07 Mar 2009 17:28:59 +0100 (CET) Cc: Andrew Sullivan , bmanning@vacation.karoshi.com, Edward Lewis , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 16:28:37 -0000 > does this mean my chances for ^B. are nil? :) Go for it! I claim ^S jaap From drc@virtualized.org Sat Mar 7 09:14:12 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9E028C10F for ; Sat, 7 Mar 2009 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHzuveaYkVqI for ; Sat, 7 Mar 2009 09:14:11 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 92E9F28B56A for ; Sat, 7 Mar 2009 09:14:11 -0800 (PST) Received: from [10.0.1.6] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id D0A4C4A5920; Sat, 7 Mar 2009 09:14:42 -0800 (PST) Message-Id: <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 07:14:40 -1000 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 17:14:12 -0000 Patrik, On Mar 7, 2009, at 5:33 AM, Patrik F=E4ltstr=F6m wrote: > If you want a TLD, you tell me that you will not create any harm. =20 > You do, you get the domain, things go poof, then you did not do your =20= > homework beforehand. So, just to be clear, you would disallow new top-level domains unless =20= you can prove a negative? :-) Regards, -drc From paul.hoffman@vpnc.org Sat Mar 7 10:19:56 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEEF28C136 for ; Sat, 7 Mar 2009 10:19:56 -0800 (PST) X-Quarantine-ID: <8vx5hx70JJjb> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E4 hex): To: Patrik F\344ltstr\366m ; Sat, 7 Mar 2009 10:19:55 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F13643A6B2B for ; Sat, 7 Mar 2009 10:19:54 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n27IKKPh058601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Mar 2009 11:20:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> Date: Sat, 7 Mar 2009 10:19:54 -0800 To: Patrik Fältström From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:19:56 -0000 At 12:07 PM +0100 3/7/09, Patrik Fältström wrote: >I think regarding digits in TLDs (or rather, non-letters), this is the right time when one definitely should have the basic rule to not "add something until it breaks", but instead, "only add things we do know will not create any harm". Yes, that's a good statement. >And I think within those basic rules, we should just say no to digits in TLDs. Anywhere. Or rather, every character in a U-label in a TLD have to have an explicit directionality. I'm not sure I agree that we should go that far. It is clear that TLDs should not start with digits because of bad BiDi interactions. I thought that a TLD of "E164" (to take a controversial example...) is known to cause no harm at a TLD due to BiDi issues, but I could be wrong. All labels will be to the left of it. There is a LtoR character at the beginning. Is there a legal U-label that can go before it that will cause the "E" or any digits to move? I have no idea about, for example, "164" as a TLD. >I think it is time to not have a general rule "lets add something if not proven that adding will create harm", but instead "lets add something only if proven that it absolutely not does create any harm", and then have the people that want certain dangerous characters in there explain why it is safe. I'm with Patrik on this one: you have to prove the negative in order to register a TLD. --Paul Hoffman, Director --VPN Consortium From sm@resistor.net Sat Mar 7 10:21:21 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6F528C12F for ; Sat, 7 Mar 2009 10:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtfyfhXAKCLX for ; Sat, 7 Mar 2009 10:21:21 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0811A3A6B2B for ; Sat, 7 Mar 2009 10:21:21 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n27ILemv006579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Mar 2009 10:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1236450111; x=1236536511; bh=7rlepxc5+vs0qqs8LEfdCfdHBGwN3ze1Bk+8Z38s7uc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=olmvQiLiEePBMTgGH5puTMK5GF0jT4RG/K1c0IWdl02pSv4IwP2j2RJTSyr5jzUNI LqpYBz5pJk2YpgwT9NNxqAXQOiS6Z+OkXGfQN8N0SLm/g3+7WbCbSxa8JM58tOx5gv xtg1c3fqYLdV66BbDbEcK85jfxcQhY4AP5ICR09E= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ZlBqwLvpwXGytsgw3GovueCNElvsK3sPmJ7RE1HbyiLGR+b6g47+ZK92QFWiKfex+ T6xKHz/LJRn9V+A8K7b4foj/n6yeimVOywD/y/Cu7abfLazgIy3jCUsRIHtNZf5zjY+ 1Km0+h893FRfI33DFO2uMjVeA4pzZ9dRIp1gh84= Message-Id: <6.2.5.6.2.20090307100147.02c5a878@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Mar 2009 10:21:21 -0800 To: dnsop@ietf.org From: SM In-Reply-To: <20090307150129.GC15014@shinkuro.com> References: <20090304010001.D285A3A68CF@core3.amsl.com> <6.2.5.6.2.20090306215832.02cd2838@resistor.net> <20090307150129.GC15014@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:21:21 -0000 At 07:01 07-03-2009, Andrew Sullivan wrote: >I'm not sure I understand the worry here: the document reads perfectly >clearly, to my eyes, that other organizations may have something to >say about actual TLDs; the draft is only about the _technical_ >specification of what may be in the TLD. I don't have any concern as long as the draft is clearly read as being about a technical specification and that it is understood that other organizations might have something to say about actual TLDs. >No: 'and it MUST start with an ASCII "letter"'. Therefore, it can't >be numeric only. In another thread I've been playing devil's >advocate, attempting to see if there is any argument for weakening >that position. So far, none, I'm delighted to say. I'm glad to see that we won't have to go through a long discussion about numeric host names for this draft. :-) Are the words "name" and "label" used interchangeably in this draft? Regards, -sm From patrik@frobbit.se Sat Mar 7 10:40:19 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E13F28C0F5 for ; Sat, 7 Mar 2009 10:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z92kGoFA2bgy for ; Sat, 7 Mar 2009 10:40:18 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 5B12C3A68ED for ; Sat, 7 Mar 2009 10:40:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2E0983FC7A7A; Sat, 7 Mar 2009 19:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzzED9Iy+8-X; Sat, 7 Mar 2009 19:40:48 +0100 (CET) Received: from [192.168.1.46] (frobbit.cust.teleservice.net [85.30.128.225]) by srv01.frobbit.se (Postfix) with ESMTP id 16D773FC7A6B; Sat, 7 Mar 2009 19:40:48 +0100 (CET) Message-Id: <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-19-446009188" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 19:40:46 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:40:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-19-446009188 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 7 mar 2009, at 18.14, David Conrad wrote: > On Mar 7, 2009, at 5:33 AM, Patrik F=E4ltstr=F6m wrote: >> If you want a TLD, you tell me that you will not create any harm. =20 >> You do, you get the domain, things go poof, then you did not do =20 >> your homework beforehand. > > So, just to be clear, you would disallow new top-level domains =20 > unless you can prove a negative? :-) I guess so... :-) The problem with writing exact objective rules is that with the 6000 =20 languages, and enormous number of codepoints, it is extremely hard to =20= create say a regular expression that we know is _absolutely_ correct =20 regarding separating the good TLDs from the bad ones. I.e. I think we first of all have to accept there is a gray area, and =20= whether a TLD label in that area is safe or not very much will depend =20= on the context it is used. One of the important contexts is of course =20= the 2nd level domain which is defined by the policy for that domain. Without knowing the policy for the 2nd level domain, I think it is =20 very hard to say whether a given TLD level is safe or not. Yes, I =20 agree that "if a TLD label is beginning with letter" is pretty ok, but =20= it is safer to say "do not start or end with a digit" (as we do not =20 know whether the labels are written in a left to right or right to =20 left context). Will there also be a problem with digits within a =20 label? "Probably not", but I rather see a generic good definition of =20 "the gray area" and who is responsible for arguing (I an not saying =20 proving here) whether something is "ok to delegate" or not, and I =20 think it should be the applicant that argue it is ok. Not the other =20 way around. Patrik --Apple-Mail-19-446009188 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJsr+urMabGguI180RAgWeAKCDGsAMe4KNBEuqMgsphZwlqhOa6wCfYBJ+ IoQ8H5eGP/6mwJDqdXwtjPw= =gyjP -----END PGP SIGNATURE----- --Apple-Mail-19-446009188-- From drc@virtualized.org Sat Mar 7 12:04:04 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373EB28C17F for ; Sat, 7 Mar 2009 12:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.947 X-Spam-Level: X-Spam-Status: No, score=-6.947 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz59cOnzIA5S for ; Sat, 7 Mar 2009 12:04:03 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 830233A659B for ; Sat, 7 Mar 2009 12:04:03 -0800 (PST) Received: from [10.0.1.6] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 3658A4A5E4C; Sat, 7 Mar 2009 12:04:32 -0800 (PST) Message-Id: <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 10:04:30 -1000 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:04:04 -0000 Patrik, On Mar 7, 2009, at 8:40 AM, Patrik F=E4ltstr=F6m wrote: > The problem with writing exact objective rules is that with the 6000 =20= > languages, and enormous number of codepoints, it is extremely hard =20 > to create say a regular expression that we know is _absolutely_ =20 > correct regarding separating the good TLDs from the bad ones. Agreed. > Without knowing the policy for the 2nd level domain, I think it is =20 > very hard to say whether a given TLD level is safe or not. Unfortunately, as you're aware, policy at the second level varies over =20= time and there are few (if any) limitations placed upon the evolution =20= of that policy. Attempts by ICANN to constrain 2nd level policy would =20= unlikely be a bit ... challenging (particularly in the ccTLD space). > Yes, I agree that "if a TLD label is beginning with letter" is =20 > pretty ok, but it is safer to say "do not start or end with a =20 > digit" (as we do not know whether the labels are written in a left =20 > to right or right to left context). Will there also be a problem =20 > with digits within a label? "Probably not", but I rather see a =20 > generic good definition of "the gray area" and who is responsible =20 > for arguing (I an not saying proving here) whether something is "ok =20= > to delegate" or not, and I think it should be the applicant that =20 > argue it is ok. Not the other way around. As far as I can tell, such arguments would be subjective. The =20 applicant will obviously have an incentive to argue "of course it =20 isn't going to cause any problems" which puts the burden back on ICANN =20= to figure out if the applicant is being exhaustive in examining all =20 possible implications of the proposed label. Not sure how much that =20 helps... Regards, -drc From patrik@frobbit.se Sat Mar 7 12:12:09 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667E83A693F for ; Sat, 7 Mar 2009 12:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UkZOkXI3DJk for ; Sat, 7 Mar 2009 12:12:08 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 6112228C12F for ; Sat, 7 Mar 2009 12:12:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id C62BB3FCAC05; Sat, 7 Mar 2009 21:12:39 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkerO54BiTgz; Sat, 7 Mar 2009 21:12:39 +0100 (CET) Received: from [192.168.1.46] (frobbit.cust.teleservice.net [85.30.128.225]) by srv01.frobbit.se (Postfix) with ESMTP id 3E4813FCABF6; Sat, 7 Mar 2009 21:12:39 +0100 (CET) Message-Id: <384C8A3D-DC42-4509-A165-63D375CEC4E4@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-34-451520795" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 21:12:38 +0100 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:12:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-34-451520795 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 7 mar 2009, at 21.04, David Conrad wrote: > On Mar 7, 2009, at 8:40 AM, Patrik F=E4ltstr=F6m wrote: >> The problem with writing exact objective rules is that with the =20 >> 6000 languages, and enormous number of codepoints, it is extremely =20= >> hard to create say a regular expression that we know is =20 >> _absolutely_ correct regarding separating the good TLDs from the =20 >> bad ones. > > Agreed. > >> Without knowing the policy for the 2nd level domain, I think it is =20= >> very hard to say whether a given TLD level is safe or not. > > Unfortunately, as you're aware, policy at the second level varies =20 > over time and there are few (if any) limitations placed upon the =20 > evolution of that policy. Attempts by ICANN to constrain 2nd level =20= > policy would unlikely be a bit ... challenging (particularly in the =20= > ccTLD space). True...so, and to clarify my earlier statement. I think personally it =20= is absolutely safe to allow TLDs that consists of codepoints that have =20= a so called strong directionality. If the directionality is the same. =20= This will definitely allow both RTL and LTR labels. Now we can from this add more things, for example, talk about whether =20= other codepoints (like digits) can be part of the label, etc. But we should be careful, very careful. It is hard to undo such a =20 decision as we all know. And remember that a domain name can exist in =20= various contexts, including of course the ones where there is text =20 "after" the TLD (if you look in logical order), and we might have any =20= text there, like a digit, different directionality etc. Patrik --Apple-Mail-34-451520795 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFJstU2rMabGguI180RAtzkAJ9r9++kNt4JJjB9tT8y8b8PAo/3HQCfXCf/ IAZhyva48sRTK//Ro/xBleI= =D4Tg -----END PGP SIGNATURE----- --Apple-Mail-34-451520795-- From pk@techfak.uni-bielefeld.de Sat Mar 7 14:48:12 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769913A677C for ; Sat, 7 Mar 2009 14:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pschqVrCsLNQ for ; Sat, 7 Mar 2009 14:48:11 -0800 (PST) Received: from smarthost.TechFak.Uni-Bielefeld.DE (smarthost.piip.TechFak.Uni-Bielefeld.DE [129.70.137.17]) by core3.amsl.com (Postfix) with ESMTP id 3CF963A672F for ; Sat, 7 Mar 2009 14:48:11 -0800 (PST) Received: from asahi.TechFak.Uni-Bielefeld.DE (asahi.TechFak.Uni-Bielefeld.DE [129.70.137.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 7301F48359 for ; Sat, 7 Mar 2009 23:48:41 +0100 (CET) Message-Id: <200903072248.n27MmfBc003566@asahi.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: asahi.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs From: Peter Koch To: IETF DNSOP WG In-reply-to: Your message of "Fri, 06 Mar 2009 22:58:58 PST." <6.2.5.6.2.20090306215832.02cd2838@resistor.net> Date: Sat, 07 Mar 2009 23:48:41 +0100 Sender: pk@techfak.uni-bielefeld.de Subject: Re: [DNSOP] draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:48:12 -0000 SM wrote: > The topic discussed in draft-liman-tld-names-00 has two angles, the > application angle and the DNS angle. The "requirements" can be > different depending on which angle we are looking at. From Section > 11 of RFC 2181: I'd like to support this distinction and would suggest we keep in mind the important IDNAbis issues, but also look at the original text in RFC 1123 that prompted Liman's suggestion: > There are some clarifications about the syntax of an Internet host > name in Section 2 of RFC 1123. The "Discussion" part of that section mentions: > > "However, a valid host name can never have the dotted-decimal > form #.#.#.#, since at least the highest-level component label > will be alphabetic." This is probably the ambiguity that draft-liman-tld-names-00 mentions. "will be alphabetic" would not only exclude digits in the TLD, let alone "numeric TLDs", but also IDN TLDs in the first place, since "alphabetic" might not include the "-" character. It is also unclear to me whether this text was meant (or, probably more importantly: was subsequently read) as descriptive or normative and the lack of 'normative language' doesn't help because we're in pre-2026 times. > According to Section 2 of draft-liman-tld-names-00, the top level > domain label can be numeric only. This can lead to confusion if we > cannot determine whether the string is a FQDN or an IP address. The draft says: ! A TLD label] MUST consist of only ASCII characters from the groups ! "letters" (A-Z), "digits" (0-9) and "hyphen" (-), and it MUST start ! with an ASCII "letter", and it MUST NOT end with a "hyphen". This would clearly suggest against 'numeric' TLD labels. However, it also opens the question why the relaxation of the first character wouldn't apply to the TLD itself. > From Section 2.1 of RFC 1912 (Informational): > > "You should also be careful to not have addresses which are valid > alternate syntaxes to the inet_ntoa() library call. For example 0xe > is a valid name, but if you were to type "telnet 0xe", it would try > to connect to IP address 0.0.0.14. It is also rumored that there > exists some broken inet_ntoa() routines that treat an address like > x400 as an IP address." This is a known effect and something that truly belongs into any caveats like section. Unless this behavior (or other creative forms of writing an IPv4 address) is specified in any kind of standard, it's probably more an issue of the user interface. {ceterum censeo, 1912 needs an update ...} {quoted text moved down here:} > The title of the document is "Top Level Domain Name > Specification". If it is about gTLDs, some may see this as a matter > for some other organization instead of the IETF. Section 4 of the > draft requests IANA to change its registration process to use the > specification. Is the registration process set by the IETF or an > other organization? It's a version -00 draft, so this needs more thought and discussion. My personal opinion is that the request goes to the "wrong IANA", since the IANA considerations section is bound by RFC 2860. There might be other ways to achieve the same goal, if and when the draft becomes a technical clarification within the DNS (as opposed to IDN). -Peter From mansaxel@besserwisser.org Sat Mar 7 18:24:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7983A6B9B for ; Sat, 7 Mar 2009 18:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyJ6LJLulI0c for ; Sat, 7 Mar 2009 18:24:36 -0800 (PST) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by core3.amsl.com (Postfix) with ESMTP id C5D333A6B93 for ; Sat, 7 Mar 2009 18:24:36 -0800 (PST) Received: from rasmus.kthnoc.net (213.65.69.41) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB0415932D; Sun, 8 Mar 2009 03:25:07 +0100 Received: from localhost (localhost [127.0.0.1]) by rasmus.kthnoc.net (Postfix) with ESMTP id DFC2A19775DB; Sun, 8 Mar 2009 03:25:04 +0100 (CET) Date: Sun, 08 Mar 2009 03:25:03 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: David Conrad , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> In-Reply-To: <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1A43144E9371CDFA24FE==========" Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 02:24:37 -0000 --==========1A43144E9371CDFA24FE========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On l=C3=B6rdag, l=C3=B6rdag 7 mar 2009 10.04.30 -1000 David Conrad wrote: >> Without knowing the policy for the 2nd level domain, I think it is =20 >> very hard to say whether a given TLD level is safe or not. >=20 > Unfortunately, as you're aware, policy at the second level varies over > time and there are few (if any) limitations placed upon the evolution of > that policy. Attempts by ICANN to constrain 2nd level policy would > unlikely be a bit ... challenging (particularly in the ccTLD space). Does not ISO3166 solve that problem for us with regards to allowed characters in the TLD label?=20 --=20 M=C3=A5ns Nilsson M A C H I N A Tex SEX! The HOME of WHEELS! The dripping of COFFEE!! Take me to Minnesota but don't EMBARRASS me!! --==========1A43144E9371CDFA24FE========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFJsyyA02/pMZDM1cURAvEIAJ9s4Dqrpeld+V2/0Byz04lgCKOlvgCcDilu 74abcLcZBJQChOSHkP0KGA0= =6dv1 -----END PGP SIGNATURE----- --==========1A43144E9371CDFA24FE==========-- From drc@virtualized.org Sat Mar 7 18:31:39 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C99F3A6833 for ; Sat, 7 Mar 2009 18:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N5es5GrkMsZ for ; Sat, 7 Mar 2009 18:31:38 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 9F9DE3A67EE for ; Sat, 7 Mar 2009 18:31:38 -0800 (PST) Received: from [10.0.1.6] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 6259E4A69E7; Sat, 7 Mar 2009 18:32:09 -0800 (PST) Message-Id: <5EC52896-27B5-405A-BCFF-631F43EDBAD7@virtualized.org> From: David Conrad To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= In-Reply-To: <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 16:32:07 -1000 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 02:31:39 -0000 On Mar 7, 2009, at 4:25 PM, M=E5ns Nilsson wrote: > Does not ISO3166 solve that problem for us with regards to allowed > characters in the TLD label? Nope. ISO-3166 merely defines the list IANA uses when an entity on =20 the ISO-3166 list requests the delegation of a top-level domain. =20 ISO-3166 is irrelevant to non-ccTLDs (including gTLDs, sTLDs, and =20 {g,s,cc}IDN TLDs). Regards, -drc From mansaxel@besserwisser.org Sat Mar 7 19:56:54 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A537F3A6842 for ; Sat, 7 Mar 2009 19:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hlIdz3cI8ul for ; Sat, 7 Mar 2009 19:56:54 -0800 (PST) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by core3.amsl.com (Postfix) with ESMTP id DE6913A68A4 for ; Sat, 7 Mar 2009 19:56:53 -0800 (PST) Received: from rasmus.kthnoc.net (213.65.69.41) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB04159BB3; Sun, 8 Mar 2009 04:57:25 +0100 Received: from localhost (localhost [127.0.0.1]) by rasmus.kthnoc.net (Postfix) with ESMTP id 51B291977A47; Sun, 8 Mar 2009 04:57:23 +0100 (CET) Date: Sun, 08 Mar 2009 04:57:22 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: David Conrad Message-ID: In-Reply-To: <5EC52896-27B5-405A-BCFF-631F43EDBAD7@virtualized.org> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> <5EC52896-27B5-405A-BCFF-631F43EDBAD7@virtualized.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========FB4929D38F87C816647C==========" Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 03:56:54 -0000 --==========FB4929D38F87C816647C========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On l=C3=B6rdag, l=C3=B6rdag 7 mar 2009 16.32.07 -1000 David Conrad wrote: > On Mar 7, 2009, at 4:25 PM, M=C3=A5ns Nilsson wrote: >> Does not ISO3166 solve that problem for us with regards to allowed >> characters in the TLD label? >=20 > Nope. ISO-3166 merely defines the list IANA uses when an entity on the > ISO-3166 list requests the delegation of a top-level domain. ISO-3166 is > irrelevant to non-ccTLDs (including gTLDs, sTLDs, and {g,s,cc}IDN TLDs). And as usual my post made perfect sense until I had pressed send..=20 I mean, that for the (previously alleged to be more "interesting wrt IDN") ccTLD part of the name space, ISO 3166, with its (at least actual if not formal) limitation to two characters from A-Z, should "fix" the issue of IDNA in TLD labels, leaving the gTLDs to break...=20 =20 --=20 M=C3=A5ns Nilsson M A C H I N A Don't hit me!! I'm in the Twilight Zone!!! --==========FB4929D38F87C816647C========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFJs0Ii02/pMZDM1cURAhBEAKCi0mDBCHd7UQRAtzaWgR0ksaXLJQCdHufC TIF12bB5vfXAFwyCpyeICdA= =+m2t -----END PGP SIGNATURE----- --==========FB4929D38F87C816647C==========-- From sm@resistor.net Sun Mar 8 00:31:53 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13173A6A9B for ; Sun, 8 Mar 2009 00:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QZkLI5r-XEM for ; Sun, 8 Mar 2009 00:31:53 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 161013A67D6 for ; Sun, 8 Mar 2009 00:31:53 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n288WETJ014574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Mar 2009 00:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1236501142; x=1236587542; bh=2vWMgCkPmQmB8cHDXhTVD3EnVAYWAvjCsOHmsnmdb5I=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=tsA2su14qFTjc3F/9qlRezjXKQdGeySpYQOSYNrWF6yrHHhyEeMHBWqnMIREDxnw4 tPaR4VkzKBGIea9U0KKcaxZ7HrDqoThA3tqoW9tB8M9XG+OWn7LWHMv0l6blCvu7xe TrJrFtrp+MmxVTl+WKqce14SnM5CpneBMm/XrkXA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=x2NedEoCNekwRn6G6F7eUr4AlnyR/asvepQMwfcrG7irKHbq5sGIG2BvnO/us5IrY CwF0tx82H11GgEifyozm+OdKRJMRImxLFkN/HDLrnk+I/15eQqxENH3FJy4ip8coVO+ y0lHWSEv90cdqR1ATRKlA6xxvUzOSIrzz3f1NyQ= Message-Id: <6.2.5.6.2.20090307205820.02bebf08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Mar 2009 00:14:29 -0800 To: IETF DNSOP WG From: SM In-Reply-To: <200903072248.n27MmfBc003566@asahi.TechFak.Uni-Bielefeld.DE > References: <200903072248.n27MmfBc003566@asahi.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 08:31:54 -0000 At 14:48 07-03-2009, Peter Koch wrote: >I'd like to support this distinction and would suggest we keep in mind the >important IDNAbis issues, but also look at the original text in RFC 1123 >that prompted Liman's suggestion: This is an opportunity to look at Section 2.1 of RFC 1123 as the distinction is unclear within the IETF community and in other communities. >This is probably the ambiguity that draft-liman-tld-names-00 mentions. >"will be alphabetic" would not only exclude digits in the TLD, let alone >"numeric TLDs", but also IDN TLDs in the first place, since "alphabetic" >might not include the "-" character. Relaxing or clarifying the ambiguity of the "alphabetic rule" takes us into the "do no harm" arena. That "rule" allows us to sidestep some possible issues if we are looking at ASCII-only TLDs only. >It is also unclear to me whether this text was meant (or, probably more >importantly: was subsequently read) as descriptive or normative >and the lack of 'normative language' doesn't help because we're in >pre-2026 times. Agreed. The text provides an explanation of the "requirements text". If we want to be conservative, we can read it as clarifying the intent when that specification was written, i.e. "we can avoid the problem altogether by doing this". >This would clearly suggest against 'numeric' TLD labels. However, it >also opens the question why the relaxation of the first character wouldn't >apply to the TLD itself. If we remove the alphabetic constraint on the first character, we then have to list the exceptions (e.g. 0xe) or craft rules to cover them. >This is a known effect and something that truly belongs into any caveats >like section. Unless this behavior (or other creative forms of writing >an IPv4 address) is specified in any kind of standard, it's probably >more an issue of the user interface. As the issue affects application-layer protocols, it would be better to address it as part of some 1123 or 1123-related effort. >{ceterum censeo, 1912 needs an update ...} Agreed. That entails a text rewrite or some creativity as it is pre-2026 material. >It's a version -00 draft, so this needs more thought and discussion. >My personal opinion is that the request goes to the "wrong IANA", since >the IANA considerations section is bound by RFC 2860. There might be >other ways to achieve the same goal, if and when the draft becomes >a technical clarification within the DNS (as opposed to IDN). The guidelines for the IANA considerations Section is covered in RFC 5226. I share your opinion that the IANA considerations in the draft may fit under RFC 2860. As this is a version -00 draft, the question could be left open for now. Regards, -sm From jim@rfc1035.com Sun Mar 8 00:38:43 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5EE3A68E5 for ; Sun, 8 Mar 2009 00:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-nFnP3Rqd09 for ; Sun, 8 Mar 2009 00:38:42 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 3902D3A68C1 for ; Sun, 8 Mar 2009 00:38:42 -0800 (PST) Received: from [195.54.233.69] (HELO gromit.rfc1035.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTP id 403022; Sun, 08 Mar 2009 08:39:13 +0000 Message-Id: <46B59E42-F563-42D0-A13E-C065954726B3@rfc1035.com> From: Jim Reid To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 08:39:13 +0000 References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <92F8E9C2-74ED-45FE-B4AC-D4395872F62B@virtualized.org> <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> <5EC52896-27B5-405A-BCFF-631F43EDBAD7@virtualized.org> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG , David Conrad Subject: [DNSOP] IDNs and ccTLDs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 08:38:43 -0000 On 8 Mar 2009, at 03:57, M=C3=A5ns Nilsson wrote: > I mean, that for the (previously alleged to be more "interesting wrt =20= > IDN") > ccTLD part of the name space, ISO 3166, with its (at least actual if =20= > not > formal) limitation to two characters from A-Z, should "fix" the =20 > issue of > IDNA in TLD labels, leaving the gTLDs to break... If only it could be that simple. There already are some IDN labels in =20= the root for test purposes: .xn--zckzah for instance is the Katakana =20 for "test" (=E3=83=86=E3=82=B9=E3=83=88). For ccTLDs the direction that = ICANN appears to =20 be heading probably means IDN labels for each country representing the =20= name of that country in the languages/scripts used there. The ISO 3166 =20= list won't matter in that context. A government or ccTLD is likely to =20= go to ICANN and say "Here are the IDN strings that represent our =20 country name in our national languages/scripts. Put them in the =20 root." What happens for the existing gTLDs and sTLDs is anyone's =20 guess.... ICANN is looking to the IETF to come up with a deterministic way of =20 checking these IDN labels and provide confirmation that they don't do =20= any damage: like break the installed base or somehow destabilise the =20 DNS. Once the IETF has devised this process, ICANN will apply it to =20 any of the zillions of new TLDs they want to create. I'm with Patrik on this one: those proposing new TLD labels should be =20= required to prove that they do no harm. However that's impractical =20 because it means proving a negative. [OTOH it would be a very =20 effective brake on the TLD free-for-all that ICANN seems to want.] =20 This approach is unlikely to be acceptable to ICANN. They'd like to =20 have a deterministic (automated?) method to validate applications for =20= new TLDs. A possible compromise solution might be to come up with an algorithm =20 which filters out the obviously broken or dangerous TLD labels. =20 Assuming such a thing can be devised of course.... Then if a proposed =20= label passes that threshold, it goes out for wider consultation to =20 allow the world to object on technical grounds that the introduction =20 of the new TLD would break something. Which begs the question: what =20 happens when operational problems arise after the new TLD is introduced?= From jaap@bartok.nlnetlabs.nl Sun Mar 8 01:59:00 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D36D3A6A2F for ; Sun, 8 Mar 2009 01:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inx5gW7kgVYZ for ; Sun, 8 Mar 2009 01:59:00 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id AF1E03A697F for ; Sun, 8 Mar 2009 01:58:59 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n289xGiZ000180; Sun, 8 Mar 2009 10:59:16 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200903080959.n289xGiZ000180@bartok.nlnetlabs.nl> To: =?UTF-8?Q?M=C3=A5ns_Nilsson?= In-reply-to: Your message of Sun, 08 Mar 2009 03:25:03 +0100. <943D60CD4E99E363D561D3D4@rasmus.kthnoc.net> Date: Sun, 08 Mar 2009 10:59:16 +0100 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Sun, 08 Mar 2009 10:59:16 +0100 (CET) Cc: IETF DNSOP WG , David Conrad Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 09:59:00 -0000 Does not ISO3166 solve that problem for us with regards to allowed characters in the TLD label? No. The alpha-2 used for ccTLD labels (and also the alpha-3) codes are restricted to the set A-Z. jaap From mansaxel@besserwisser.org Sun Mar 8 08:04:24 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA60A3A68DD for ; Sun, 8 Mar 2009 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwIzoZWptR+F for ; Sun, 8 Mar 2009 08:04:24 -0700 (PDT) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by core3.amsl.com (Postfix) with ESMTP id E30C23A67DB for ; Sun, 8 Mar 2009 08:04:23 -0700 (PDT) Received: from rasmus.kthnoc.net (213.65.69.41) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A979500665D2C2; Sun, 8 Mar 2009 16:04:55 +0100 Received: from localhost (localhost [127.0.0.1]) by rasmus.kthnoc.net (Postfix) with ESMTP id 0D4FC1978083; Sun, 8 Mar 2009 16:04:51 +0100 (CET) Date: Sun, 08 Mar 2009 16:04:51 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: Jaap Akkerhuis Message-ID: In-Reply-To: <200903080959.n289xGiZ000180@bartok.nlnetlabs.nl> References: <200903080959.n289xGiZ000180@bartok.nlnetlabs.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D4023ED5DD0F7F2CED2A==========" Cc: IETF DNSOP WG , David Conrad Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 15:04:24 -0000 --==========D4023ED5DD0F7F2CED2A========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On s=C3=B6ndag, s=C3=B6ndag 8 mar 2009 10.59.16 +0100 Jaap Akkerhuis wrote: > =20 > Does not ISO3166 solve that problem for us with regards to allowed > characters in the TLD label? >=20 > No. The alpha-2 used for ccTLD labels (and also the alpha-3) codes > are restricted to the set A-Z. ...so for those there will be no problems.=20 I have since been kindly informed by Patrik that while the original ISO 3166 codes are "safe", there, as Jim also wrote, will be a lot of new top level domains. In IDN. I would agree with Patrik and Jim, that these need to prove themselves safe, FSVO safe, first.=20 /M=C3=A5ns, clue finally beaten in.=20 --=20 M=C3=A5ns Nilsson M A C H I N A Yow! --==========D4023ED5DD0F7F2CED2A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFJs96T02/pMZDM1cURAirvAJwLF7UMo78J0/V+rQo3Pmv3i8TV6QCePvi2 TvURHUD5MpDhOhRZ38GQeU4= =XSj8 -----END PGP SIGNATURE----- --==========D4023ED5DD0F7F2CED2A==========-- From ajs@shinkuro.com Sun Mar 8 08:29:32 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494513A67D1 for ; Sun, 8 Mar 2009 08:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZxrLbgovoGT for ; Sun, 8 Mar 2009 08:29:31 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7B0DA3A693A for ; Sun, 8 Mar 2009 08:29:31 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C3D752FEA556 for ; Sun, 8 Mar 2009 15:30:03 +0000 (UTC) Date: Sun, 8 Mar 2009 11:30:02 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090308153001.GB15436@shinkuro.com> References: <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 15:29:32 -0000 On Sat, Mar 07, 2009 at 07:40:46PM +0100, Patrik Fältström wrote: > The problem with writing exact objective rules is that with the 6000 > languages, and enormous number of codepoints, it is extremely hard to > create say a regular expression that we know is _absolutely_ correct > regarding separating the good TLDs from the bad ones. I'm not sure the "good TLDs from the bad ones" is what the I-D in question is trying to separate. I have the impression, from reading it, that the I-D is trying to talk about the narrow, technical definition of the last label aside from the null-length root one, as it appears in the DNS -- what we call "TLDs", but only in the narrow, technical sense of "the label appearing in the DNS protocol". The document has nothing to say about languages, code points, good policy, &c -- it's very careful, in fact, to say that it's not tackling that question, and is only interested in the DNS definition of labels at a particular level. I appreciate that perhaps the other questions are important ones that need tackling. But we have a narrow, technical problem right now that needs to be addressed: at the moment, depending on how one reads RFC 1123, the IANA-operated root zone has in it labels that it should not, because it contains labels that are not "alphabetic". I would like to suggest that we need to solve that specific issue first, just so that we even have something else to talk about. If we can't solve that issue, then one might reasonably argue that the current IANA-operated root zone is in violation of RFC 1123, and try to prevent additional movement on internationalized TLDs that way. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From fw@deneb.enyo.de Sun Mar 8 11:16:30 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0088F28C0DE for ; Sun, 8 Mar 2009 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqJWLjYuBqv1 for ; Sun, 8 Mar 2009 11:16:29 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by core3.amsl.com (Postfix) with ESMTP id 111CD28C0F9 for ; Sun, 8 Mar 2009 11:16:29 -0700 (PDT) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LgNYS-0008Uq-6f; Sun, 08 Mar 2009 19:16:52 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1LgNYR-00058r-Ds; Sun, 08 Mar 2009 19:16:51 +0100 From: Florian Weimer To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090304165539.GN6574@shinkuro.com> <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> Date: Sun, 08 Mar 2009 19:16:51 +0100 In-Reply-To: ("Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=22's?= message of "Sat, 7 Mar 2009 16:35:49 +0100") Message-ID: <87ocwblw18.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis , David Conrad Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 18:16:30 -0000 * Patrik F=C3=A4ltstr=C3=B6m: > On 7 mar 2009, at 16.25, David Conrad wrote: > >> Define "harm". > > Here is a link to one of the blog pages of mine that show in a > filesystem what I think is "harm" if we allow mix of codepoints etc > that give same result(s) for domain names. > > http://stupid.domain.name/node/681 [Bidi rendering alters the hierarchy expressed in a path name.] > I claim that is "harm". It's an unfortunate result of the bidi rules, I agree. But even without that, it can be difficult to spot the domain part of a Unicode URL: But I agree that it's more significant with bidi URLs: (Iceweasel shows the TLD at the end of the URL, but still left-justifies it.) It's possible to fix this for the browser by reconsidering how the URL is displayed (straightforward left-justification is not that great even for ASCII, after all). As a result, the ordinary, in-print rendering would differ quite significantly from the visual end result. This isn't a problem as long as it's clear to a read of the printed representation how to enter it in the browser. I'm not familiar with any right-to-left language, so I haven't got an answer to that. From ogud@ogud.com Mon Mar 9 08:14:43 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16D33A6C34 for ; Mon, 9 Mar 2009 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KsepmhyM+r9 for ; Mon, 9 Mar 2009 08:14:42 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9D1753A69E7 for ; Mon, 9 Mar 2009 08:14:42 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n29FFETP055827; Mon, 9 Mar 2009 11:15:14 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200903091515.n29FFETP055827@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Mar 2009 11:12:30 -0400 To: Paul Hoffman , dnsop@ietf.org From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_777355448==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:14:44 -0000 --=====================_777355448==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 13:46 06/08/2008, Paul Hoffman wrote: >Greetings again. The end of section 2 of this document says: > Another advantage of configuring a trust anchor using a DS record is > that the entire hash of the public key in the DS RDATA need not > necessarily be specified. A validating resolver MAY support > configuration using a truncated DS hash value as a human-factors > convenience: shorter strings are easier to type and less prone to > error when entered manually. Even with a truncated hash configured, > a validating resolver can still verify that the corresponding DNSKEY > is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 > [RFC2104] offers guidance on acceptable truncation lengths. > >This is not correct. You cannot say "here is the SHA-256 hash of a >value" and then give less than 256 bits of the hash. If you wanted >to do this, you need to define the truncated hash and use that new >hash algorithm. So far, none of these truncated hashes have been >defined for DNSSEC, although ones could be defined. > >Further, it is somewhat optimistic (and possibly sadistic) to think >that a user can type Base64 by hand for more than maybe ten >characters. This document should assume that the user is using >copy-and-paste, and therefore using the full 256 bits of the hash is >just as easy as using a truncated hash. If not, new, inherently >weaker, truncated hash algorithms need to be defined. > >--Paul Hoffman, Director >--VPN Consortium >_ You are not the first person to bring this issue up, and upon reflection we have dropped truncation discussion. Olafur --=====================_777355448==.ALT Content-Type: text/html; charset="us-ascii" At 13:46 06/08/2008, Paul Hoffman wrote:
Greetings again. The end of section 2 of this document says:
   Another advantage of configuring a trust anchor using a DS record is
   that the entire hash of the public key in the DS RDATA need not
   necessarily be specified.  A validating resolver MAY support
   configuration using a truncated DS hash value as a human-factors
   convenience: shorter strings are easier to type and less prone to
   error when entered manually.  Even with a truncated hash configured,
   a validating resolver can still verify that the corresponding DNSKEY
   is present in the trust anchor zone's apex DNSKEY RRSet.  RFC 2104
   [RFC2104] offers guidance on acceptable truncation lengths.

This is not correct. You cannot say "here is the SHA-256 hash of a value" and then give less than 256 bits of the hash. If you wanted to do this, you need to define the truncated hash and use that new hash algorithm. So far, none of these truncated hashes have been defined for DNSSEC, although ones could be defined.

Further, it is somewhat optimistic (and possibly sadistic) to think that a user can type Base64 by hand for more than maybe ten characters. This document should assume that the user is using copy-and-paste, and therefore using the full 256 bits of the hash is just as easy as using a truncated hash. If not, new, inherently weaker, truncated hash algorithms need to be defined.

--Paul Hoffman, Director
--VPN Consortium
_

You are not the first person to bring this issue up, and upon reflection
we have dropped truncation discussion.

        Olafur


--=====================_777355448==.ALT-- From ogud@ogud.com Mon Mar 9 08:29:06 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A563A67AF for ; Mon, 9 Mar 2009 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ83FdotK+tm for ; Mon, 9 Mar 2009 08:29:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C1B893A67B3 for ; Mon, 9 Mar 2009 08:29:05 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n29FFETR055827; Mon, 9 Mar 2009 11:15:15 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200903091515.n29FFETR055827@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Mar 2009 10:58:14 -0400 To: Paul Hoffman , dnsop@ietf.org From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_777355468==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [DNSOP] Questions on section 3 of draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:29:06 -0000 --=====================_777355468==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed We have had an off-line discussion with Paul on how to address his comments and this is the result of that discussion. New version will show up RSN. At 13:55 06/08/2008, Paul Hoffman wrote: >Greetings again. Section 3 of this document says: > If any of the steps above result in an error, the validating resolver > SHOULD log them. > >...and then what? Continue on merrily as if the priming worked? Just >logging the error seems like undershooting the security of using trust anchors. > >Later in that section, it says: > If a validating resolver is unable to retrieve a signed DNSKEY RRSet > corresponding to a trust anchor (i.e., prime the trust anchor), it > SHOULD log this condition as an error. Inability to prime a zone's > trust anchor results in the validating resolver's inability to > validate data from the corresponding zone. The validating resolver > SHOULD treat this zone as bogus. > >It is not clear why not being able to get the DNSKEY RRSet is more >serious (and thus worth bogofying the zone) than the validating >steps not working. The new version of the draft will have an explicit pointer to RFC4035 saying that TA processing errors should be treated the same way as DS processing errors. >Further, the last sentence has a "SHOULD" but doesn't say under what >circumstances that a resolver can ignore the "SHOULD". Why isn't this a "MUST"? You are right the new version says "MUST" thanks for your comments. Olafur --=====================_777355468==.ALT Content-Type: text/html; charset="us-ascii" We have had an off-line discussion with Paul on how to address his comments
and this is the result of that discussion.
New version will show up RSN.


At 13:55 06/08/2008, Paul Hoffman wrote:
Greetings again. Section 3 of this document says:
   If any of the steps above result in an error, the validating resolver
   SHOULD log them.

...and then what? Continue on merrily as if the priming worked? Just logging the error seems like undershooting the security of using trust anchors.

Later in that section, it says:
   If a validating resolver is unable to retrieve a signed DNSKEY RRSet
   corresponding to a trust anchor (i.e., prime the trust anchor), it
   SHOULD log this condition as an error.  Inability to prime a zone's
   trust anchor results in the validating resolver's inability to
   validate data from the corresponding zone.  The validating resolver
   SHOULD treat this zone as bogus.

It is not clear why not being able to get the DNSKEY RRSet is more serious (and thus worth bogofying the zone) than the validating steps not working.

The new version of the draft will have an explicit pointer to
RFC4035 saying that TA processing errors should be treated the
same way as DS processing errors.


Further, the last sentence has a "SHOULD" but doesn't say under what circumstances that a resolver can ignore the "SHOULD". Why isn't this a "MUST"?

You are right the new version says "MUST"

thanks for your comments.

        Olafur

--=====================_777355468==.ALT-- From root@core3.amsl.com Mon Mar 9 08:30:01 2009 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BB8A13A6961; Mon, 9 Mar 2009 08:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309153001.BB8A13A6961@core3.amsl.com> Date: Mon, 9 Mar 2009 08:30:01 -0700 (PDT) Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Trust Anchor Configuration and Maintenance Author(s) : M. Larson, O. Gudmundsson Filename : draft-ietf-dnsop-dnssec-trust-anchor-03.txt Pages : 14 Date : 2009-03-09 This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initialize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsop-dnssec-trust-anchor-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09082538.I-D@ietf.org> --NextPart-- From johani@autonomica.se Mon Mar 9 09:22:21 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778213A69DE for ; Mon, 9 Mar 2009 09:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VYlzVBYth3d for ; Mon, 9 Mar 2009 09:22:20 -0700 (PDT) Received: from defiant.autonomica.se (mail.autonomica.se [IPv6:2a01:3f0:1:3::105]) by core3.amsl.com (Postfix) with ESMTP id 9C5123A699F for ; Mon, 9 Mar 2009 09:22:19 -0700 (PDT) Received: from [IPv6:2a01:3f0:1::217:f2ff:fed9:877b] (unknown [IPv6:2a01:3f0:1:0:217:f2ff:fed9:877b]) (Authenticated sender: johani) by defiant.autonomica.se (Postfix) with ESMTPSA id A8FAE18E986; Mon, 9 Mar 2009 17:22:52 +0100 (CET) Message-Id: <1E4A1951-584A-4C57-86F4-797A5EC7F0E3@autonomica.se> From: Johan Ihren To: Richard Lamb In-Reply-To: <05B243F724B2284986522B6ACD0504D789082168AA@EXVPMBX100-1.exc.icann.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 17:22:50 +0100 References: <05B243F724B2284986522B6ACD0504D789082168AA@EXVPMBX100-1.exc.icann.org> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Cc: "Stephen.Morris@nominet.org.uk" , "dnsop@ietf.org" Subject: Re: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:22:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Richard, On 4 Mar 2009, at 09:58, Richard Lamb wrote: > A very useful piece of work. Particularly the material on emergency =20= > key rollover. It took me some time to write the scripts to take into =20= > account TTL, propagation delays, and various key compromise =20 > scenarios. The approach your work takes gives the implementer a =20 > clear framework. Wish I had your work before. Thanks. The emergency rollover logic in the draft is based on =20 experience from several failed implementation attempts that kept =20 sending us back to the proverbial drawing board. Once we got it =20 "right" implementation suddenly became quite easy. To me, a large part of the point with this draft is to take a much =20 needed step from "rollover confusion" (which is where most of us spend =20= time up during our initial implementation efforts) to "rollover =20 analysis" (where it is possible to actually have a rational discussion =20= about different rollover logic alternatives). But, having tried to =20 have such discussions with a number of people it seemed clear that we =20= needed some sort of "reference logic" first. Hence this draft. Regards, Johan > -----Original Message----- > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On =20 > Behalf Of Stephen.Morris@nominet.org.uk > Sent: Tuesday, February 17, 2009 10:21 AM > To: dnsop@ietf.org > Subject: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00 > > John Dickinson and Johan Ihren and I have just submitted > = http://www.ietf.org/internet-drafts/draft-morris-dnsop-dnssec-key-timing-0= 0.txt > > The draft gives a rigorous description of timing considerations in =20 > DNSSEC > key rollovers. > > Stephen > > > >> A new version of I-D, draft-morris-dnsop-dnssec-key-timing-00.txt >> has been successfuly submitted by Stephen Morris and posted to the >> IETF repository. >> >> Filename: draft-morris-dnsop-dnssec-key-timing >> Revision: 00 >> Title: DNSSEC Key Timing Considerations >> Creation_date: 2009-02-17 >> WG ID: Independent Submission >> Number_of_pages: 22 >> >> Abstract: >> RFC 4641 gives a detailed overview of the operational considerations >> involved in running a DNSSEC-secured zone, including key rollovers. >> This document expands on the previous work, and discusses timing >> considerations in greater depth. It explicitly identifies the >> relationships between the various time parameters, and gives a >> suggested algorithm for key rollover in a DNSSEC-secured zone. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBSbVCXPotlDfa2H4ZAQJjPQQAj4QlWr6jhg3+2xChwTFYvtsLRqO4LqQW X8pb7RO0/cdxzA+QlKCfin0QsIUoYkGvmT0VbMWs1d1gAUc8TcvEERaJzi7Xwv7G kzeFCUVx+AFHw3/hBFxK2HGrx8pJ8ZhtjLvWBKCXtrBbTehG+18cQx+MuuauIOiY kKuLjI3hRuA=3D =3DSIUu -----END PGP SIGNATURE----- From ajs@shinkuro.com Mon Mar 9 10:04:12 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC843A6359 for ; Mon, 9 Mar 2009 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roOTToT24Phi for ; Mon, 9 Mar 2009 10:04:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7BD4B3A695B for ; Mon, 9 Mar 2009 10:04:10 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EC7A32FEA4F4 for ; Mon, 9 Mar 2009 17:04:43 +0000 (UTC) Date: Mon, 9 Mar 2009 13:04:42 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090309170441.GH16211@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:04:12 -0000 Dear colleagues, I mentioned that I would request some feedback about draft-liman-tld-names-00.txt from the idnabis WG participants. I got some remarks, off-list and not about the particular BiDi issue I was wondering about, from John Klensin. He told me he doesn't have time to engage here, but told me to feel free to pass along his comments. Any mistakes in the statement of his position are mine, and I apologise in advance if I don't get this right. Nevertheless, I think he has a point worth considering. John's view is that the original "alphabetic restriction" in 1123 was indeed intended as a restriction, and that top-level labels were in fact intended only ever to be characters of the ASCII alphabet. He argues that it is a good idea to be as restrictive as possible in the top level, and that therefore it would be a wise idea to broaden the "alphabetic restriction" as little as possible. His suggestion is to re-iterate the alphabetic-only criterion, except to allow one extension to permit A-labels conforming to IDNA2008 (which work, note, is not yet complete). In addition, I think he believes that the document should also require that any U-label that is to correspond with an A-label that is added to the root zone must _also_ be alphabetic. The reasoning behind this is that the root zone occupies a very sensitive place in the tree, and therefore technical specifications around what is allowed in it should be very conservative. The above outline gives the minimum change to permit IDNs in the top level, without also leaving room for any other innovation in the labels allowed. It is worth noting that, since there are many commercial interests at stake here, one must suppose that anything that _might_ be possible in the root will be tried by someone. If that's right, then one can argue on prudential grounds that 1123 needs to be modified as little as possible to permit exactly the change we wish to enable, and no other. I will say that I am (personally, no hats) uneasy importing to the technical constraints on top level labels what seem to me to be policy considerations. Such policy considerations seem to me to be the sort of thing that ought to be handled in policy-making bodies set up for the purpose. At the same time, I accept the argument that there are strong technical reasons to minimize the changes to rules about the root zone, since we know there are many DNS-using systems in the world built around fragile readings of various RFCs. So I'm of two minds about the position I've laid out above. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Mon Mar 9 10:38:22 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850913A695B for ; Mon, 9 Mar 2009 10:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEGujHpWmts4 for ; Mon, 9 Mar 2009 10:38:21 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 85FE93A6358 for ; Mon, 9 Mar 2009 10:38:19 -0700 (PDT) Received: from [10.31.200.116] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n29Hcn08057944; Mon, 9 Mar 2009 13:38:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090309170441.GH16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> Date: Mon, 9 Mar 2009 13:35:08 -0400 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:38:22 -0000 At 13:04 -0400 3/9/09, Andrew Sullivan (based on someone else's note) wrote: >His suggestion is to re-iterate the alphabetic-only criterion, >except to allow one extension to permit A-labels conforming to >IDNA2008 (which work, note, is not yet complete). In addition, I >think he believes that the document should also require that any >U-label that is to correspond with an A-label that is added to the >root zone must _also_ be alphabetic. For those of us not reading idnabis, what is an A-label and what is a U-label? I have not seen a reference to their definition so I'm assuming these are idnabis terms. >I will say that I am (personally, no hats) uneasy importing to the >technical constraints on top level labels what seem to me to be policy >considerations. Such policy considerations seem to me to be the sort >of thing that ought to be handled in policy-making bodies set up for >the purpose. At the same time, I accept the argument that there are >strong technical reasons to minimize the changes to rules about the >root zone, since we know there are many DNS-using systems in the world >built around fragile readings of various RFCs. So I'm of two minds >about the position I've laid out above. The problem with saying "these are the technical rules and they shouldn't be changed" is that this essentially closes off the global public Internet from becoming global. If the Internet is based on "fragile readings of various RFCs" then the Internet should be the entity that "suffers" not the world economy it serves. I understand the advantages of maintaining technical purity, but what good is it if the purity was defined by a small percentage of the population and then the putiry maintained resulting in there being an "technical elite? (Even I have relatives that do not speak English.) I agree though that "policy...ought to be handled in policy-making bodies." I have used the statement "bus drivers shouldn't determine the bus route" a few times in the past - meaning here that having DNS experts determine the rules for what's to be allowed in the global public Internet root zone is a misplaced assignment. For engineers, no change in the specification is always good. For the DNS, it doesn't matter what's in that root (so long as it's globally coherent). But it matters to a lot of other protocols. Ultimately, I think that there are no technical restrictions on what is placed in the root, no algorithmic way to say "thumbs up" or say "thumbs down." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much. From paul.hoffman@vpnc.org Mon Mar 9 10:54:41 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472243A6B1E for ; Mon, 9 Mar 2009 10:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roRFVtp9LbN5 for ; Mon, 9 Mar 2009 10:54:40 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1B5B83A69DE for ; Mon, 9 Mar 2009 10:54:39 -0700 (PDT) Received: from [165.227.249.200] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29HtBZd070499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 10:55:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090309170441.GH16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> Date: Mon, 9 Mar 2009 10:55:10 -0800 To: Andrew Sullivan , dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:54:41 -0000 At 1:04 PM -0400 3/9/09, Andrew Sullivan wrote: >His suggestion is to re-iterate the alphabetic-only criterion, >except to allow one extension to permit A-labels conforming to >IDNA2008 (which work, note, is not yet complete). In addition, I >think he believes that the document should also require that any >U-label that is to correspond with an A-label that is added to the >root zone must _also_ be alphabetic. ...give or take. Some language/script combinations require non-alphabetic characters to represent real words. The people who speak those languages would not call those characters "non-alphabetic". For example, if Unicode required you to have two characters to represent "e with umlaut", and "e" and a "combining umlaut", one can argue ad nauseam whether or not "combining umlaut" was alphabetic. There is not a technical name for "alphabetic and the additional characters you need to form words", nor is there a definitive list. A suggestion would be "word characters, explicitly excluding numerals and symbol characters" (because some people might say that a copyright character is a word character). >I will say that I am (personally, no hats) uneasy importing to the >technical constraints on top level labels what seem to me to be policy >considerations. Such policy considerations seem to me to be the sort >of thing that ought to be handled in policy-making bodies set up for >the purpose. At the same time, I accept the argument that there are >strong technical reasons to minimize the changes to rules about the >root zone, since we know there are many DNS-using systems in the world >built around fragile readings of various RFCs. So I'm of two minds >about the position I've laid out above. +2 (+1 for each mind), unfortunately. --Paul Hoffman, Director --VPN Consortium From patrik@frobbit.se Mon Mar 9 10:55:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC993A6BB0 for ; Mon, 9 Mar 2009 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uahv02BvDC1Y for ; Mon, 9 Mar 2009 10:55:02 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 86AB83A6B1E for ; Mon, 9 Mar 2009 10:55:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 370FC404CD6A; Mon, 9 Mar 2009 18:55:36 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF+xDPHzMvi7; Mon, 9 Mar 2009 18:55:36 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id EFCC2404CD59; Mon, 9 Mar 2009 18:55:35 +0100 (CET) Message-Id: <9F99BC6E-2D9D-4205-9980-1E1D8F929C0A@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Edward Lewis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 18:55:35 +0100 References: <20090309170441.GH16211@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:55:03 -0000 On 9 mar 2009, at 18.35, Edward Lewis wrote: > For those of us not reading idnabis, what is an A-label and what is > a U-label? I have not seen a reference to their definition so I'm > assuming these are idnabis terms. In short, an A-label is what is registered in DNS (xn-- version) and U- label is the equivalent but in Unicode. There are some details of course, but this is the 30000 foot level view. Patrik From ajs@shinkuro.com Mon Mar 9 10:56:18 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F63F3A69DE for ; Mon, 9 Mar 2009 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iywez+vIY46l for ; Mon, 9 Mar 2009 10:56:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 98EE03A68A9 for ; Mon, 9 Mar 2009 10:56:17 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3B7B42FEA4F4 for ; Mon, 9 Mar 2009 17:56:51 +0000 (UTC) Date: Mon, 9 Mar 2009 13:56:49 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090309175649.GJ16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:56:18 -0000 On Mon, Mar 09, 2009 at 01:35:08PM -0400, Edward Lewis wrote: > For those of us not reading idnabis, what is an A-label and what is a > U-label? I have not seen a reference to their definition so I'm > assuming these are idnabis terms. Oops, sorry, yes, I should have provided that. An A-label is the ASCII-compatible-encoding version of an IDNA-legal string. Basically, these are the labels you see in the DNS that start with "xn--". Note that traditional labels (all ASCII ones that people use, like "shinkuro" and "com") are _not_ A-labels. A U-label is the Unicode "version" of the label -- that is, the thing that we expect people to see and to type in. It must include at least one non-ASCII character (otherwise, it's just an ASCII label, and IDNA doesn't kick in). There are some other restrictions having to do with the legal form for U-labels, but they're beyond our scope for the purposes of this discussion. > The problem with saying "these are the technical rules and they > shouldn't be changed" is that this essentially closes off the global > public Internet from becoming global. Surely not, if we are defining an infrastructure by which that "globalness" may be expressed (i.e. IDNA). Or is there some other thing you think ought to be permitted that would be closed off by John's position? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From drc@virtualized.org Mon Mar 9 11:16:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8103A6922 for ; Mon, 9 Mar 2009 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVdLR+pvuYRZ for ; Mon, 9 Mar 2009 11:16:02 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id A69FC28C255 for ; Mon, 9 Mar 2009 11:16:02 -0700 (PDT) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id B1F294AAEB4; Mon, 9 Mar 2009 11:16:36 -0700 (PDT) Message-Id: <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> From: David Conrad To: Andrew Sullivan In-Reply-To: <20090309170441.GH16211@shinkuro.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 11:16:36 -0700 References: <20090309170441.GH16211@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:16:03 -0000 On Mar 9, 2009, at 10:04 AM, Andrew Sullivan wrote: > I think he believes that the document should also require that any > U-label that is to correspond with an A-label that is added to the > root zone must _also_ be alphabetic. This doesn't make any sense to me. I am fairly certain there will be =20= a request to add the U-label "=E6=97=A5=E6=9C=AC" (Japanese Kanji for = Japan). This =20 isn't alphabetic in any sense of the term. Interestingly, I tried a couple of IDN test tools (IMC's and NASK's) =20 to convert that UTF-8 string into the appropriate A-label and both =20 indicated there are invalid characters. I'm getting an uneasy =20 feeling... Regards, -drc From Ed.Lewis@neustar.biz Mon Mar 9 11:19:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6773B28C261 for ; Mon, 9 Mar 2009 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkwPKzDn4JF2 for ; Mon, 9 Mar 2009 11:19:19 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1219028C28F for ; Mon, 9 Mar 2009 11:18:19 -0700 (PDT) Received: from [10.31.200.116] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n29IInJC058522; Mon, 9 Mar 2009 14:18:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090309175649.GJ16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090309175649.GJ16211@shinkuro.com> Date: Mon, 9 Mar 2009 14:11:13 -0400 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:19:20 -0000 At 13:56 -0400 3/9/09, Andrew Sullivan wrote: >"globalness" may be expressed (i.e. IDNA). Or is there some other >thing you think ought to be permitted that would be closed off by >John's position? I'm not sure (as this is all second hand arguing). ;) I have gotten the feeling that some folks, perhaps John/perhaps not, have been arguing that the specs in 1123 were sacred and ought not to change lest other bad things happen. IOW, maintaining the status quo of a "working Internet" was imperative. I suppose my confusion is now a bit deeper. If A-labels conform to the rules in 1123 and all U-labels can be translated to A-labels, is BiDi an issue (for the DNS)? If A-labels are what is in the DNS, isn't the DNS taken care-of? And therefore all of this talk about what U-labels are good for TLDs belongs in fora for other protocols (URL's/IRL's, SMTP, etc.) or policy on things like bundling (ICANN)? BTW, I was under the impression that ICANN wanted a root zone without any confusion, no homonyms, etc., but the IDN test bed has that - the two Chinese-language[0] entries are pronounced the same but written differently. [0] Mandarin/simplified and Mandarin/traditional -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much. From ajs@shinkuro.com Mon Mar 9 11:32:30 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22CE28C122 for ; Mon, 9 Mar 2009 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKu9QcQZZ2xg for ; Mon, 9 Mar 2009 11:32:29 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CF32C3A6B63 for ; Mon, 9 Mar 2009 11:32:29 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6C0A92FEA4F4 for ; Mon, 9 Mar 2009 18:33:03 +0000 (UTC) Date: Mon, 9 Mar 2009 14:33:01 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090309183301.GK16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090309175649.GJ16211@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:32:30 -0000 On Mon, Mar 09, 2009 at 02:11:13PM -0400, Edward Lewis wrote: > I'm not sure (as this is all second hand arguing). ;) I have gotten the > feeling that some folks, perhaps John/perhaps not, have been arguing that > the specs in 1123 were sacred and ought not to change lest other bad > things happen. IOW, maintaining the status quo of a "working Internet" > was imperative. No, I think John is arguing that IDNs at the top level are a good idea, but opening things any wider would be bad. I think his position is very similar to what Patrik argued, which was that we ought to require people to show that there is not a harm before allowing the innovation at the top level, rather than presuming that there's no harm and reacting if we run into one. > I suppose my confusion is now a bit deeper. If A-labels conform to the > rules in 1123 and all U-labels can be translated to A-labels, is BiDi an > issue (for the DNS)? A labels do _not_ conform to 1123. 1123 says "alphabetic", and all A-labels have at least two hyphen-minus ("-") characters in them. That's part of why we have a problem. > If A-labels are what is in the DNS, isn't the DNS taken care-of? Maybe. That's what I was asking in idnabis about. It isn't clear to me yet whether it is possible for an A-label (which is always xn--[output from Punycode algorithm]) to end with a digit instead of always a letter. I _think_ it's always a letter, but I'm not totally sure. You can definitely have digits inside a Punycode-encoded label, because I've seen them. We may want to restrict any A-label that happens to end with a digit anyway, because of what might happen if that label is exposed in A-label form, but in a BiDi context. > BTW, I was under the impression that ICANN wanted a root zone without > any confusion, no homonyms, etc., but the IDN test bed has that - the > two Chinese-language[0] entries are pronounced the same but written > differently. I am happy to report that I do not know anything about what ICANN wants in respect of the contents of the root zone, and that I don't yet think I need to learn. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Mon Mar 9 11:35:56 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CCC3A6BE9 for ; Mon, 9 Mar 2009 11:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H3Kb8spGW1W for ; Mon, 9 Mar 2009 11:35:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EB2233A6970 for ; Mon, 9 Mar 2009 11:35:55 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 87BD72FEA4F4 for ; Mon, 9 Mar 2009 18:36:29 +0000 (UTC) Date: Mon, 9 Mar 2009 14:36:27 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090309183627.GL16211@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:35:56 -0000 On Mon, Mar 09, 2009 at 11:16:36AM -0700, David Conrad wrote: > This doesn't make any sense to me. I am fairly certain there will be a > request to add the U-label "日本" (Japanese Kanji for Japan). This > isn't alphabetic in any sense of the term. See Paul's note about this. The point is that one might try to restrict numbers. My opinion, in any case, is that anything having to do with U-labels is completely outside the scope of any document focussed on the DNS: no U-label should ever be anywhere close to a zone file. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From root@core3.amsl.com Mon Mar 9 13:15:01 2009 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AEA063A6A8A; Mon, 9 Mar 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309201501.AEA063A6A8A@core3.amsl.com> Date: Mon, 9 Mar 2009 13:15:01 -0700 (PDT) Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action:draft-ietf-dnsop-as112-ops-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : AS112 Nameserver Operations Author(s) : J. Abley, W. Maton Filename : draft-ietf-dnsop-as112-ops-02.txt Pages : 23 Date : 2009-03-09 Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-as112-ops-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsop-as112-ops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09130815.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 13:15:01 2009 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B96D03A6A8D; Mon, 9 Mar 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309201501.B96D03A6A8D@core3.amsl.com> Date: Mon, 9 Mar 2009 13:15:01 -0700 (PDT) Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action:draft-ietf-dnsop-as112-under-attack-help-help-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : I'm Being Attacked by PRISONER.IANA.ORG! Author(s) : J. Abley, W. Maton Filename : draft-ietf-dnsop-as112-under-attack-help-help-02.txt Pages : 17 Date : 2009-03-09 Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send DNS reverse mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-as112-under-attack-help-help-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsop-as112-under-attack-help-help-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09130853.I-D@ietf.org> --NextPart-- From Mark_Andrews@isc.org Mon Mar 9 14:35:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997053A696F for ; Mon, 9 Mar 2009 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yGzWJQzWJOP for ; Mon, 9 Mar 2009 14:35:19 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 63CF23A69DE for ; Mon, 9 Mar 2009 14:35:19 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 7DE63114028; Mon, 9 Mar 2009 21:35:46 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D220AE6074; Mon, 9 Mar 2009 21:35:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n29LZejx079303; Tue, 10 Mar 2009 08:35:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903092135.n29LZejx079303@drugs.dv.isc.org> To: Olafur Gudmundsson From: Mark Andrews In-reply-to: Your message of "Mon, 09 Mar 2009 11:12:30 EDT." <200903091515.n29FFETP055827@stora.ogud.com> Date: Tue, 10 Mar 2009 08:35:40 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:35:20 -0000 In message <200903091515.n29FFETP055827@stora.ogud.com>, Olafur Gudmundsson wri tes: > --===============0733757033== > Content-Type: multipart/alternative; > boundary="=====================_777355448==.ALT" > > --=====================_777355448==.ALT > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 13:46 06/08/2008, Paul Hoffman wrote: > >Greetings again. The end of section 2 of this document says: > > Another advantage of configuring a trust anchor using a DS record is > > that the entire hash of the public key in the DS RDATA need not > > necessarily be specified. A validating resolver MAY support > > configuration using a truncated DS hash value as a human-factors > > convenience: shorter strings are easier to type and less prone to > > error when entered manually. Even with a truncated hash configured, > > a validating resolver can still verify that the corresponding DNSKEY > > is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 > > [RFC2104] offers guidance on acceptable truncation lengths. > > > >This is not correct. You cannot say "here is the SHA-256 hash of a > >value" and then give less than 256 bits of the hash. If you wanted > >to do this, you need to define the truncated hash and use that new > >hash algorithm. So far, none of these truncated hashes have been > >defined for DNSSEC, although ones could be defined. > > > >Further, it is somewhat optimistic (and possibly sadistic) to think > >that a user can type Base64 by hand for more than maybe ten > >characters. This document should assume that the user is using > >copy-and-paste, and therefore using the full 256 bits of the hash is > >just as easy as using a truncated hash. If not, new, inherently >weaker, truncated hash algorithms need to be defined. > > > >--Paul Hoffman, Director > >--VPN Consortium > >_ > > You are not the first person to bring this issue up, and upon reflection > we have dropped truncation discussion. > > Olafur On a related issue DS -> DNSKEY translations cannot be performed until the DNSKEY is published in the zone. The use of DS prevents pre-publishing of keys. I can see no real reason to recommend that DS records be published in preference to DNSKEY records. DNSKEY -> DS is a conversion that can be at anytime. This make DNSKEY a better manditory record to publish. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From davidb@verisign.com Mon Mar 9 15:59:08 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7404728C1D0 for ; Mon, 9 Mar 2009 15:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bptOaXktkuf4 for ; Mon, 9 Mar 2009 15:59:07 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id A91003A6884 for ; Mon, 9 Mar 2009 15:59:07 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n29MpdE1006141; Mon, 9 Mar 2009 18:51:39 -0400 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 18:59:39 -0400 Received: from dul1mcdblacka-l2.vcorp.ad.vrsn.com ([10.131.29.149]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 18:59:37 -0400 Message-Id: From: David Blacka To: Mark Andrews In-Reply-To: <200903092135.n29LZejx079303@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 18:58:41 -0400 References: <200903092135.n29LZejx079303@drugs.dv.isc.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Mar 2009 22:59:37.0977 (UTC) FILETIME=[B8D96690:01C9A10A] Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:59:08 -0000 On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: > > On a related issue DS -> DNSKEY translations cannot be > performed until the DNSKEY is published in the zone. The > use of DS prevents pre-publishing of keys. Huh? You can generate a DS from the DNSKEY record that you have generated but not yet published, so you can pre-publish the DS just as soon as you could pre-publish your DNSKEY. As for actually *using* the DS as a trust anchor, you can't use either the DS or the DNSKEY prior to actually publishing and *using* the DNSKEY. Or maybe I just don't understand your point. > > I can see no real reason to recommend that DS records be > published in preference to DNSKEY records. They are small and easier to eyeball as correct. > > DNSKEY -> DS is a conversion that can be at anytime. > > This make DNSKEY a better manditory record to publish. I don't follow. -- David Blacka Sr. Engineer VeriSign Platform Product Development From Mark_Andrews@isc.org Mon Mar 9 18:55:27 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3374E3A6897 for ; Mon, 9 Mar 2009 18:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skp-iIgcdmNb for ; Mon, 9 Mar 2009 18:55:26 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 52A213A68C0 for ; Mon, 9 Mar 2009 18:55:26 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 9086F114039; Tue, 10 Mar 2009 01:55:56 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D1C13E6064; Tue, 10 Mar 2009 01:55:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2A1tpP0083041; Tue, 10 Mar 2009 12:55:52 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903100155.n2A1tpP0083041@drugs.dv.isc.org> To: David Blacka From: Mark Andrews In-reply-to: Your message of "Mon, 09 Mar 2009 18:58:41 EDT." Date: Tue, 10 Mar 2009 12:55:51 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 01:55:27 -0000 In message , David Blacka wr ites: > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: > > > > On a related issue DS -> DNSKEY translations cannot be > > performed until the DNSKEY is published in the zone. The > > use of DS prevents pre-publishing of keys. > > Huh? You can generate a DS from the DNSKEY record that you have > generated but not yet published, so you can pre-publish the DS just as > soon as you could pre-publish your DNSKEY. As for actually *using* > the DS as a trust anchor, you can't use either the DS or the DNSKEY > prior to actually publishing and *using* the DNSKEY. Or maybe I just > don't understand your point. When you pre-publish a DS you prevent implementations that use DNSKEYs from taking advantage of that pre-publication. When you pre-prepublish DNSKEYs implementations that use DS or DNSKEYs can taking advantage of that pre-publication. > > I can see no real reason to recommend that DS records be > > published in preference to DNSKEY records. > > They are small and easier to eyeball as correct. > > > DNSKEY -> DS is a conversion that can be at anytime. > > > > This make DNSKEY a better manditory record to publish. > > I don't follow. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From A.Hoenes@tr-sys.de Mon Mar 9 19:50:05 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D753A6B16 for ; Mon, 9 Mar 2009 19:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQFd1i-Gk7xA for ; Mon, 9 Mar 2009 19:50:04 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id DB48C3A6803 for ; Mon, 9 Mar 2009 19:49:59 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA260893314; Tue, 10 Mar 2009 03:48:34 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id DAA07637; Tue, 10 Mar 2009 03:48:32 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903100248.DAA07637@TR-Sys.de> To: namedroppers@ops.ietf.org, dnsop@ietf.org Date: Tue, 10 Mar 2009 03:48:32 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [DNSOP] New Version Notification for draft-mcgrew-tss-02 (fwd) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 02:50:05 -0000 This tools might be of interest for implementors of DNSSEC, e.g. the folks wanting to distibute control over the future Root Zone primary Key Signing Keys between the RIRs and ICANN/IANA. The new version should hopefully be ready for implementation. ----- Forwarded message from IETF I-D Submission Tool ----- > From: IETF I-D Submission Tool > Message-Id: <20090309204424.AD5F73A687B@core3.amsl.com> > Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) > Subject: New Version Notification for draft-mcgrew-tss-02 A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly submitted by David McGrew and posted to the IETF repository. Filename: draft-mcgrew-tss Revision: 02 Title: Threshold Secret Sharing Creation_date: 2009-03-09 WG ID: Independent Submission Number_of_pages: 26 Abstract: Threshold secret sharing (TSS) provides a way to generate N shares from a value, so that any M of those shares can be used to reconstruct the original value, but any M-1 shares provide no information about that value. This method can provide shared access control on key material and other secrets that must be strongly protected. This note defines a threshold secret sharing method based on polynomial interpolation in GF(256) and a format for the storage and transmission of shares. It also provides usage guidance, describes how to test an implementation, and supplies test cases. The IETF Secretariat. ----- End of forwarded message from IETF I-D Submission Tool ----- 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 | +------------------------+--------------------------------------------+ From bmanning@karoshi.com Mon Mar 9 21:10:48 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0017C3A6C84 for ; Mon, 9 Mar 2009 21:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkdscZ3u7kbr for ; Mon, 9 Mar 2009 21:10:47 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 08F143A6891 for ; Mon, 9 Mar 2009 21:10:47 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n2A4BCff005004; Tue, 10 Mar 2009 04:11:13 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n2A4B51I005003; Tue, 10 Mar 2009 04:11:05 GMT Date: Tue, 10 Mar 2009 04:11:05 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Message-ID: <20090310041105.GA4987@vacation.karoshi.com.> References: <200903091515.n29FFETP055827@stora.ogud.com> <200903092135.n29LZejx079303@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903092135.n29LZejx079303@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:10:48 -0000 On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote: > > In message <200903091515.n29FFETP055827@stora.ogud.com>, Olafur Gudmundsson wri > tes: > > --===============0733757033== > > Content-Type: multipart/alternative; > > boundary="=====================_777355448==.ALT" > > > > --=====================_777355448==.ALT > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > At 13:46 06/08/2008, Paul Hoffman wrote: > > >Greetings again. The end of section 2 of this document says: > > > Another advantage of configuring a trust anchor using a DS record is > > > that the entire hash of the public key in the DS RDATA need not > > > necessarily be specified. A validating resolver MAY support > > > configuration using a truncated DS hash value as a human-factors > > > convenience: shorter strings are easier to type and less prone to > > > error when entered manually. Even with a truncated hash configured, > > > a validating resolver can still verify that the corresponding DNSKEY > > > is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 > > > [RFC2104] offers guidance on acceptable truncation lengths. > > > > > >This is not correct. You cannot say "here is the SHA-256 hash of a > > >value" and then give less than 256 bits of the hash. If you wanted > > >to do this, you need to define the truncated hash and use that new > > >hash algorithm. So far, none of these truncated hashes have been > > >defined for DNSSEC, although ones could be defined. > > > > > >Further, it is somewhat optimistic (and possibly sadistic) to think > > >that a user can type Base64 by hand for more than maybe ten > > >characters. This document should assume that the user is using > > >copy-and-paste, and therefore using the full 256 bits of the hash is > > >just as easy as using a truncated hash. If not, new, inherently > >weaker, truncated hash algorithms need to be defined. > > > > > >--Paul Hoffman, Director > > >--VPN Consortium > > >_ > > > > You are not the first person to bring this issue up, and upon reflection > > we have dropped truncation discussion. > > > > Olafur > > On a related issue DS -> DNSKEY translations cannot be > performed until the DNSKEY is published in the zone. The > use of DS prevents pre-publishing of keys. > > I can see no real reason to recommend that DS records be > published in preference to DNSKEY records. > > DNSKEY -> DS is a conversion that can be at anytime. > > This make DNSKEY a better manditory record to publish. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop if the child produces the DS, then the TTL is preserved. if the parent produces the DS, then the TTL is not. i'd think that would be a reason to use DS as the record to publish. --bill From bmanning@karoshi.com Mon Mar 9 21:12:25 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA663A6C83 for ; Mon, 9 Mar 2009 21:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UwagdZufjyo for ; Mon, 9 Mar 2009 21:12:24 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 527133A6891 for ; Mon, 9 Mar 2009 21:12:22 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n2A4Cuff005017; Tue, 10 Mar 2009 04:12:56 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n2A4CsdH005016; Tue, 10 Mar 2009 04:12:54 GMT Date: Tue, 10 Mar 2009 04:12:54 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Message-ID: <20090310041254.GB4987@vacation.karoshi.com.> References: <200903100155.n2A1tpP0083041@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903100155.n2A1tpP0083041@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Cc: David Blacka , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:12:25 -0000 On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote: > > In message , David Blacka wr > ites: > > > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: > > > > > > On a related issue DS -> DNSKEY translations cannot be > > > performed until the DNSKEY is published in the zone. The > > > use of DS prevents pre-publishing of keys. > > > > Huh? You can generate a DS from the DNSKEY record that you have > > generated but not yet published, so you can pre-publish the DS just as > > soon as you could pre-publish your DNSKEY. As for actually *using* > > the DS as a trust anchor, you can't use either the DS or the DNSKEY > > prior to actually publishing and *using* the DNSKEY. Or maybe I just > > don't understand your point. > > When you pre-publish a DS you prevent implementations that > use DNSKEYs from taking advantage of that pre-publication. sounds like an implementation bugll --bill > > When you pre-prepublish DNSKEYs implementations that use > DS or DNSKEYs can taking advantage of that pre-publication. > > > > I can see no real reason to recommend that DS records be > > > published in preference to DNSKEY records. > > > > They are small and easier to eyeball as correct. > > > > > DNSKEY -> DS is a conversion that can be at anytime. > > > > > > This make DNSKEY a better manditory record to publish. > > > > I don't follow. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From Mark_Andrews@isc.org Mon Mar 9 21:35:53 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50B128C0F1 for ; Mon, 9 Mar 2009 21:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IMZC3D3dXGQ for ; Mon, 9 Mar 2009 21:35:52 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 4A4C228C0EA for ; Mon, 9 Mar 2009 21:35:52 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 40E1911402C; Tue, 10 Mar 2009 04:36:14 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 82E8CE6079; Tue, 10 Mar 2009 04:36:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2A4aAkt084331; Tue, 10 Mar 2009 15:36:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903100436.n2A4aAkt084331@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com From: Mark Andrews In-reply-to: Your message of "Tue, 10 Mar 2009 04:11:05 -0000." <20090310041105.GA4987@vacation.karoshi.com.> Date: Tue, 10 Mar 2009 15:36:10 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:35:53 -0000 In message <20090310041105.GA4987@vacation.karoshi.com.>, bmanning@vacation.kar oshi.com writes: > On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote: > > > > In message <200903091515.n29FFETP055827@stora.ogud.com>, Olafur Gudmundsson > wri > > tes: > > > --===============0733757033== > > > Content-Type: multipart/alternative; > > > boundary="=====================_777355448==.ALT" > > > > > > --=====================_777355448==.ALT > > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > > > At 13:46 06/08/2008, Paul Hoffman wrote: > > > >Greetings again. The end of section 2 of this document says: > > > > Another advantage of configuring a trust anchor using a DS record is > > > > that the entire hash of the public key in the DS RDATA need not > > > > necessarily be specified. A validating resolver MAY support > > > > configuration using a truncated DS hash value as a human-factors > > > > convenience: shorter strings are easier to type and less prone to > > > > error when entered manually. Even with a truncated hash configured, > > > > a validating resolver can still verify that the corresponding DNSKEY > > > > is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 > > > > [RFC2104] offers guidance on acceptable truncation lengths. > > > > > > > >This is not correct. You cannot say "here is the SHA-256 hash of a > > > >value" and then give less than 256 bits of the hash. If you wanted > > > >to do this, you need to define the truncated hash and use that new > > > >hash algorithm. So far, none of these truncated hashes have been > > > >defined for DNSSEC, although ones could be defined. > > > > > > > >Further, it is somewhat optimistic (and possibly sadistic) to think > > > >that a user can type Base64 by hand for more than maybe ten > > > >characters. This document should assume that the user is using > > > >copy-and-paste, and therefore using the full 256 bits of the hash is > > > >just as easy as using a truncated hash. If not, new, inherently > > >weaker, truncated hash algorithms need to be defined. > > > > > > > >--Paul Hoffman, Director > > > >--VPN Consortium > > > >_ > > > > > > You are not the first person to bring this issue up, and upon reflection > > > we have dropped truncation discussion. > > > > > > Olafur > > > > On a related issue DS -> DNSKEY translations cannot be > > performed until the DNSKEY is published in the zone. The > > use of DS prevents pre-publishing of keys. > > > > I can see no real reason to recommend that DS records be > > published in preference to DNSKEY records. > > > > DNSKEY -> DS is a conversion that can be at anytime. > > > > This make DNSKEY a better manditory record to publish. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > if the child produces the DS, then the TTL is preserved. > if the parent produces the DS, then the TTL is not. That depends on the processes used. There is no reason a parent can't produce a DS with a specified TTL. There is also no requirement for the parent to honour the ttl, if any, passed to the parent. > i'd think that would be a reason to use DS as the record to > publish. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From Mark_Andrews@isc.org Mon Mar 9 21:43:33 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377A428C0EA for ; Mon, 9 Mar 2009 21:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4qp1jahTNRe for ; Mon, 9 Mar 2009 21:43:32 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 287B33A6A98 for ; Mon, 9 Mar 2009 21:43:32 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 4DCDA114049; Tue, 10 Mar 2009 04:43:55 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 9CF78E6079; Tue, 10 Mar 2009 04:43:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2A4hqbn084431; Tue, 10 Mar 2009 15:43:52 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903100443.n2A4hqbn084431@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com From: Mark Andrews In-reply-to: Your message of "Tue, 10 Mar 2009 04:12:54 -0000." <20090310041254.GB4987@vacation.karoshi.com.> Date: Tue, 10 Mar 2009 15:43:52 +1100 Sender: Mark_Andrews@isc.org Cc: David Blacka , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:43:33 -0000 In message <20090310041254.GB4987@vacation.karoshi.com.>, bmanning@vacation.kar oshi.com writes: > On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote: > > > > In message , David Black > a wr > > ites: > > > > > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: > > > > > > > > On a related issue DS -> DNSKEY translations cannot be > > > > performed until the DNSKEY is published in the zone. The > > > > use of DS prevents pre-publishing of keys. > > > > > > Huh? You can generate a DS from the DNSKEY record that you have > > > generated but not yet published, so you can pre-publish the DS just as > > > soon as you could pre-publish your DNSKEY. As for actually *using* > > > the DS as a trust anchor, you can't use either the DS or the DNSKEY > > > prior to actually publishing and *using* the DNSKEY. Or maybe I just > > > don't understand your point. > > > > When you pre-publish a DS you prevent implementations that > > use DNSKEYs from taking advantage of that pre-publication. > > sounds like an implementation bugll draft-ietf-dnsop-dnssec-trust-anchor is unfairly trying to restrict what is can be used as a trust anchor. It is retroactively changing the specification. A security-aware resolver MUST be capable of being configured with at least one trusted public key or DS RR and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots; examples of such a mechanism would be some form of non-volatile storage (such as a disk drive) or some form of trusted local network configuration mechanism. > --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From patrik@frobbit.se Tue Mar 10 00:29:39 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D8828C0F8 for ; Tue, 10 Mar 2009 00:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQfeC8SQXgjZ for ; Tue, 10 Mar 2009 00:29:38 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id E762B3A6AFD for ; Tue, 10 Mar 2009 00:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id C5381407243A; Tue, 10 Mar 2009 08:30:11 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3hTxXKn5Bu4; Tue, 10 Mar 2009 08:30:11 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 5A78A407242C; Tue, 10 Mar 2009 08:30:11 +0100 (CET) Message-Id: <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 08:30:10 +0100 References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 07:29:39 -0000 On 9 mar 2009, at 19.16, David Conrad wrote: > This doesn't make any sense to me. I am fairly certain there will =20 > be a request to add the U-label "=E6=97=A5=E6=9C=AC" (Japanese Kanji = for Japan). =20 > This isn't alphabetic in any sense of the term. To some degree it is, as the two characters are: U+65E5 : Lo, Letter Other --> Alphabetic U+672C : Lo, Letter Other --> Alphabetic I.e. they have both the Unicode Properties of letters, and because of =20= that the derived property "Alphabetic". This compared to the character "7": U+0037 : Nd, Decimal_Number digit --> Not Alphabetic > Interestingly, I tried a couple of IDN test tools (IMC's and NASK's) =20= > to convert that UTF-8 string into the appropriate A-label and both =20 > indicated there are invalid characters. I'm getting an uneasy =20 > feeling... If you use a mac, let me recommend UnicodeChecker from = http://earthlingsoft.net Patrik From patrik@frobbit.se Tue Mar 10 00:31:45 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D54128C127 for ; Tue, 10 Mar 2009 00:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMoA3lMcosKd for ; Tue, 10 Mar 2009 00:31:44 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 6CF1F28C0F8 for ; Tue, 10 Mar 2009 00:31:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 8B3294072592; Tue, 10 Mar 2009 08:32:18 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCoch-9nP4Ja; Tue, 10 Mar 2009 08:32:18 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 54E1D4072587; Tue, 10 Mar 2009 08:32:18 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Edward Lewis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 08:32:18 +0100 References: <20090309170441.GH16211@shinkuro.com> <20090309175649.GJ16211@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 07:31:45 -0000 On 9 mar 2009, at 19.11, Edward Lewis wrote: > If A-labels conform to the rules in 1123 and all U-labels can be > translated to A-labels, is BiDi an issue (for the DNS)? The $10000 question has to do with the (for the DNS) part of what you write. Domain names are not only used in the DNS as we all know, and if you have a domain name that for example end with a "7", and you use this domain name in a text with right to left context, and some unfortunate characters adjacent to the "7". Well, then the domain name might "look weird". So it is a domain name problem, not a DNS problem. And not a (big) problem if you only look at the Domain Name in isolation. It is the context the domain name is used in which create the problem. Patrik From kolesik@nask.pl Tue Mar 10 02:05:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575193A69C7 for ; Tue, 10 Mar 2009 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMyjgbnF7EXL for ; Tue, 10 Mar 2009 02:05:14 -0700 (PDT) Received: from boromix.nask.net.pl (boromix.nask.net.pl [195.187.245.33]) by core3.amsl.com (Postfix) with ESMTP id 6BD843A687F for ; Tue, 10 Mar 2009 02:05:14 -0700 (PDT) Received: from boromir.nask.net.pl (boromir [195.187.245.66]) by boromix.nask.net.pl with ESMTP id n2A95ErE000387; Tue, 10 Mar 2009 10:05:14 +0100 Received: from [127.0.0.1] (abarth.nask.waw.pl [195.187.243.204]) by boromir.nask.net.pl with ESMTP id n2A95BZS000149; Tue, 10 Mar 2009 10:05:14 +0100 (CET) Message-ID: <49B62D45.3010605@nask.pl> Date: Tue, 10 Mar 2009 10:05:09 +0100 From: Krzysztof Olesik User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Conrad References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> In-Reply-To: <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> X-Enigmail-Version: 0.95.7 OpenPGP: url= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass (boromix.nask.net.pl: 195.187.245.66 is authenticated by a trusted mechanism) VirusProtection: checked - Found to be clean Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:05:15 -0000 Hello, Just a short explanation. > Interestingly, I tried a couple of IDN test tools (IMC's and NASK's) to > convert that UTF-8 string into the appropriate A-label and both > indicated there are invalid characters. I'm getting an uneasy feeling... IDN translation tool accepts only allowed characters for registration at NASK. I will add few words explaining this issue at the web page to avoid further confusion. Regards, Krzysztof Olesik NASK From bortzmeyer@nic.fr Tue Mar 10 02:31:48 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B56B3A6A03 for ; Tue, 10 Mar 2009 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OusyDfBdO2+g for ; Tue, 10 Mar 2009 02:31:47 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 62B753A6920 for ; Tue, 10 Mar 2009 02:31:47 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 25EB11C00F6 for ; Tue, 10 Mar 2009 10:27:21 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 213981C00F4 for ; Tue, 10 Mar 2009 10:27:21 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 1F2D9A1D97F for ; Tue, 10 Mar 2009 10:27:21 +0100 (CET) Date: Tue, 10 Mar 2009 10:27:21 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20090310092721.GA631@nic.fr> References: <20090309170441.GH16211@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090309170441.GH16211@shinkuro.com> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:31:48 -0000 On Mon, Mar 09, 2009 at 01:04:42PM -0400, Andrew Sullivan wrote a message of 59 lines which said: > John's view is that the original "alphabetic restriction" in 1123 > was indeed intended as a restriction, I was not there at the creation but I find it worrying to rely on the recollection of one specific person. The "alphabetic-only" rule in RFC 1123 is just a side note, never detailed, and presented as a fact (which it was at this time), not as a mandatory restriction. It is nice to remove the ambiguity (and therefore draft-liman-tld-names is a good idea) but it should be treated as a small adjustment, not a big reform. > He argues that it is a good idea to be as restrictive as possible in > the top level, I completely fail to see why. Most reasons given were policy issues. Here, I fully agree with Edward Lewis's law "bus drivers shouldn't determine the bus route". There are no *TECHNICAL* reasons to limit TLD to alphabetic characters. There may be non-technical reasons and even valid non-technical reasons, but they are completely off-topic for the IETF. The IETF should be really careful not being used as a pretext in policy disputes. If some governance body wants to prohibit IDN in the root (which is the case today), they must not be able to say that it is per-request of the IETF. Because this would drag IETF in the line of fire. > His suggestion is to re-iterate the alphabetic-only criterion, This would turn a small ambiguity in RFC 1123 in a real rule. -1 for me. From patrik@frobbit.se Tue Mar 10 02:37:46 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124923A69E5 for ; Tue, 10 Mar 2009 02:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhYDMvxy7Kjf for ; Tue, 10 Mar 2009 02:37:45 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 2E0963A6920 for ; Tue, 10 Mar 2009 02:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 816664078E81 for ; Tue, 10 Mar 2009 10:38:18 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl0HC3HcrTZN for ; Tue, 10 Mar 2009 10:37:59 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id B9AFC4078E58 for ; Tue, 10 Mar 2009 10:37:58 +0100 (CET) Message-Id: <79CC6BAC-5956-41F0-B105-F3CC979EEFC7@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: dnsop@ietf.org In-Reply-To: <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 10:37:58 +0100 References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> X-Mailer: Apple Mail (2.930.3) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:37:46 -0000 On 10 mar 2009, at 08.30, Patrik F=E4ltstr=F6m wrote: > If you use a mac, let me recommend UnicodeChecker from = http://earthlingsoft.net Hmm...that domain seems to be not delegated at the moment. Anyone have =20= other contacts? Patrik From bmanning@karoshi.com Tue Mar 10 03:54:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CB93A6CED for ; Tue, 10 Mar 2009 03:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y70R6w2N3HGh for ; Tue, 10 Mar 2009 03:54:02 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 3F9653A69B7 for ; Tue, 10 Mar 2009 03:54:02 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n2AAsbff007381; Tue, 10 Mar 2009 10:54:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n2AAsZpY007380; Tue, 10 Mar 2009 10:54:35 GMT Date: Tue, 10 Mar 2009 10:54:35 +0000 From: bmanning@vacation.karoshi.com To: Stephane Bortzmeyer Message-ID: <20090310105435.GB7318@vacation.karoshi.com.> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090310092721.GA631@nic.fr> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:54:03 -0000 On Tue, Mar 10, 2009 at 10:27:21AM +0100, Stephane Bortzmeyer wrote: > On Mon, Mar 09, 2009 at 01:04:42PM -0400, > Andrew Sullivan wrote > a message of 59 lines which said: > > > John's view is that the original "alphabetic restriction" in 1123 > > was indeed intended as a restriction, > > I was not there at the creation but I find it worrying to rely on the > recollection of one specific person. The "alphabetic-only" rule in RFC > 1123 is just a side note, never detailed, and presented as a fact > (which it was at this time), not as a mandatory restriction. we -could- ask the author of RFC 1123. --bill From ogud@ogud.com Tue Mar 10 05:26:10 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E017E3A699D for ; Tue, 10 Mar 2009 05:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OTSowjoRTX for ; Tue, 10 Mar 2009 05:26:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D102A3A6806 for ; Tue, 10 Mar 2009 05:26:09 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n2ACQfSN070352; Tue, 10 Mar 2009 08:26:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200903101226.n2ACQfSN070352@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 08:24:53 -0400 To: Mark Andrews , Olafur Gudmundsson From: Olafur Gudmundsson In-Reply-To: <200903092135.n29LZejx079303@drugs.dv.isc.org> References: <200903092135.n29LZejx079303@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4051095==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 ) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:26:11 -0000 --=====================_4051095==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 17:35 09/03/2009, Mark Andrews wrote: > On a related issue DS -> DNSKEY translations cannot be > performed until the DNSKEY is published in the zone. The > use of DS prevents pre-publishing of keys. Once the key is generated a DS of it can be generated. Our draft does not in any way make any assumptions about how trust anchors are "discovered" or "disseminated" What can be done with a DNSKEY TA can be done with a DS TA. DS prepublication has the further advantage that it does not expose the KEY during the "pre-publication period" preventing factoring attacks on the key during this time period. > I can see no real reason to recommend that DS records be > published in preference to DNSKEY records. We see nothing but problems by using DNSKEY records. We want to prevent the configured party from blindly using DNSKEY records by forcing it to fetch the current DNSKEY RRset and make sure the trust anchor configured is still there. By configuring DS instead of DNSKEY the processing is almost the same as it is for delegations. The last thing we want is a compromised TA can be used to sign forged answers for a long time after the compromised key is Removed/Revoked. > DNSKEY -> DS is a conversion that can be at anytime. > > This make DNSKEY a better manditory record to publish. I do not follow Olafur --=====================_4051095==.ALT Content-Type: text/html; charset="us-ascii" At 17:35 09/03/2009, Mark Andrews wrote:

        On a related issue DS -> DNSKEY translations cannot be
        performed until the DNSKEY is published in the zone.  The
        use of DS prevents pre-publishing of keys.

Once the key is generated a DS of it can be generated.

Our draft does not in any way make any assumptions about how
trust anchors are "discovered" or "disseminated"
What can be done with a DNSKEY TA can be done with a DS TA. 
DS prepublication has the further advantage that it does not expose the
KEY during the "pre-publication period" preventing factoring attacks
on the key during this time period.



        I can see no real reason to recommend that DS records be
        published in preference to DNSKEY records.

We see nothing but problems by using DNSKEY records.
We want to prevent the configured party from blindly using DNSKEY records
by forcing it to fetch the current DNSKEY RRset and make sure the trust anchor
configured is still there.
By configuring DS instead of DNSKEY the processing is almost the same as it is
for delegations. The last thing we want is a compromised TA can be used to sign
forged answers for a long time after the compromised key is Removed/Revoked.

        DNSKEY -> DS is a conversion that can be at anytime.

        This make DNSKEY a better manditory record to publish.

I do not follow

        Olafur
--=====================_4051095==.ALT-- From ogud@ogud.com Tue Mar 10 07:02:12 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249AE3A6A35 for ; Tue, 10 Mar 2009 07:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIEJ+JpfRtdc for ; Tue, 10 Mar 2009 07:02:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 82F313A6A19 for ; Tue, 10 Mar 2009 07:02:10 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n2AE2hgI071223; Tue, 10 Mar 2009 10:02:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200903101402.n2AE2hgI071223@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 10:00:47 -0400 To: Mark Andrews , bmanning@vacation.karoshi.com From: Olafur Gudmundsson In-Reply-To: <200903100443.n2A4hqbn084431@drugs.dv.isc.org> References: <200903100443.n2A4hqbn084431@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9807893==.ALT" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: David Blacka , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:02:12 -0000 --=====================_9807893==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 00:43 10/03/2009, Mark Andrews wrote: >In message <20090310041254.GB4987@vacation.karoshi.com.>, >bmanning@vacation.kar >oshi.com writes: > > On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote: > > > > > > In message , > David Black > > a wr > > > ites: > > > > > > > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote: > > > > > > > > > > On a related issue DS -> DNSKEY translations cannot be > > > > > performed until the DNSKEY is published in the zone. The > > > > > use of DS prevents pre-publishing of keys. > > > > > > > > Huh? You can generate a DS from the DNSKEY record that you have > > > > generated but not yet published, so you can pre-publish the > DS just as > > > > soon as you could pre-publish your DNSKEY. As for actually *using* > > > > the DS as a trust anchor, you can't use either the DS or the DNSKEY > > > > prior to actually publishing and *using* the DNSKEY. Or maybe I just > > > > don't understand your point. > > > > > > When you pre-publish a DS you prevent implementations that > > > use DNSKEYs from taking advantage of that pre-publication. > > > > sounds like an implementation bugll > > draft-ietf-dnsop-dnssec-trust-anchor is unfairly trying to > restrict what is can be used as a trust anchor. It is > retroactively changing the specification. > Before this draft there was NO specification what so ever on what trust anchor configuration should look like. The trusted-key statement in Bind-9 is OLDER than the DS definition. One of the disadvantages of being an early adopter is that there frequently is no guidance on the best way to do things. draft-ietf-larson-dnsop-trust-anchor-00 was published over 2 years ago. it was on the agenda of number of DNSOP meetings before begin adopted 14 months ago. This is the first time anyone has raised an issue with DS being the recommended approach, section 2 has the justification why DS is better than DNSKEY. Please explain where section 2 is wrong before asking for change in recommendation. The draft is aiming for Informational status not standards track, thus implementations are free to ignore the draft, or provide tools that take a list of DS records and translate that into trusted-key block. While DS was being defined some people wanted it to be a clone of the DNSKEY record but that approach was rejected. DS is based on PGP key finger prints and that model has held up well in the real world for creating trust relationships. > > A security-aware resolver MUST be capable of being configured with at > least one trusted public key or DS RR and SHOULD be capable of being > configured with multiple trusted public keys or DS RRs. trust-anchor draft does not violate this, just recommends one approach over the other and explains why that is better practice. We must learn from history or the same mistakes will be made. Olafur --=====================_9807893==.ALT Content-Type: text/html; charset="us-ascii" At 00:43 10/03/2009, Mark Andrews wrote:

In message <20090310041254.GB4987@vacation.karoshi.com.>, bmanning@vacation.kar
oshi.com writes:
> On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote:
> >
> > In message <F7C89744-A1CA-4FD6-B793-2F4E337E3961@verisign.com>, David Black
> a wr
> > ites:
> > >
> > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote:
> > > >
> > > >         On a related issue DS -> DNSKEY translations cannot be
> > > >         performed until the DNSKEY is published in the zone.  The
> > > >         use of DS prevents pre-publishing of keys.
> > >
> > > Huh?  You can generate a DS from the DNSKEY record that you have 
> > > generated but not yet published, so you can pre-publish the DS just as 
> > > soon as you could pre-publish your DNSKEY.  As for actually *using* 
> > > the DS as a trust anchor, you can't use either the DS or the DNSKEY 
> > > prior to actually publishing and *using* the DNSKEY.  Or maybe I just 
> > > don't understand your point.
> >
> >     When you pre-publish a DS you prevent implementations that
> >     use DNSKEYs from taking advantage of that pre-publication.
>
>       sounds like an implementation bugll

         draft-ietf-dnsop-dnssec-trust-anchor is unfairly trying to
        restrict what is can be used as a trust anchor.  It is
         retroactively changing the specification.
        

Before this draft there was NO specification what so ever on what trust
anchor configuration should look like.
The trusted-key statement in Bind-9 is OLDER than the DS definition. 
One of the disadvantages of being an early adopter is that there frequently
is no guidance on the best way to do things. 

draft-ietf-larson-dnsop-trust-anchor-00 was published over 2 years ago.
it was on the agenda of number of DNSOP meetings before begin adopted
14 months ago. This is the first time anyone has raised
an issue with DS being the recommended approach, section 2 has the
justification why DS is better than DNSKEY. Please explain where section
2 is wrong before asking for change in recommendation.
The draft is aiming for Informational status not standards track, thus
implementations are free to ignore the draft, or provide tools that
take a list of DS records and translate that into trusted-key block. 

While DS was being defined some people wanted it to be a clone of the DNSKEY record
but that approach was rejected. DS is based on PGP key finger prints and that
model has held up well in the real world for creating trust relationships.

        
   A security-aware resolver MUST be capable of being configured with at
   least one trusted public key or DS RR and SHOULD be capable of being
   configured with multiple trusted public keys or DS RRs.

trust-anchor draft does not violate this, just recommends one approach over the
other and explains why that is better practice.
We must learn from history or the same mistakes will be made.

        Olafur
 --=====================_9807893==.ALT-- From Ed.Lewis@neustar.biz Tue Mar 10 07:53:28 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687A73A687F for ; Tue, 10 Mar 2009 07:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiG3fbUFueWj for ; Tue, 10 Mar 2009 07:53:27 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D64F33A65A5 for ; Tue, 10 Mar 2009 07:53:24 -0700 (PDT) Received: from [10.31.200.116] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n2AErv77071891; Tue, 10 Mar 2009 10:53:58 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200903092135.n29LZejx079303@drugs.dv.isc.org> References: <200903092135.n29LZejx079303@drugs.dv.isc.org> Date: Tue, 10 Mar 2009 10:52:11 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: dnsop@ietf.org, ed.lewis@neustar.biz Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:53:28 -0000 At 8:35 +1100 3/10/09, Mark Andrews wrote: > This make DNSKEY a better manditory record to publish. While there's little empirical data on trust anchors to date, my inclination is to whole-heartedly disagree with this statement. So long as the DS record points to a unique DNSKEY record and the DS record involves less typing than a DNSKEY, I'd want to work with a DS record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. From drc@virtualized.org Tue Mar 10 11:06:55 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980DB28C115 for ; Tue, 10 Mar 2009 11:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9FkcMq2jwzX for ; Tue, 10 Mar 2009 11:06:51 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id DF3C128C0F3 for ; Tue, 10 Mar 2009 11:06:51 -0700 (PDT) Received: from [10.0.1.2] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 120C04ADA25; Tue, 10 Mar 2009 11:07:25 -0700 (PDT) Message-Id: From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 11:07:24 -0700 References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:06:55 -0000 Patrik, On Mar 10, 2009, at 12:30 AM, Patrik F=C3=A4ltstr=C3=B6m wrote: > On 9 mar 2009, at 19.16, David Conrad wrote: >> This doesn't make any sense to me. I am fairly certain there will =20= >> be a request to add the U-label "=E6=97=A5=E6=9C=AC" (Japanese Kanji = for =20 >> Japan). This isn't alphabetic in any sense of the term. > > To some degree it is, as the two characters are: > > U+65E5 : Lo, Letter Other --> Alphabetic > U+672C : Lo, Letter Other --> Alphabetic > > I.e. they have both the Unicode Properties of letters, and because =20 > of that the derived property "Alphabetic". Ah. A new definition for "alphabetic" of which I was unaware. Thanks, -drc P.S. Out of curiosity, what is "=E4=B8=80" (Japanese Kanji for the = number 1) =20 considered? From mstjohns@comcast.net Tue Mar 10 09:49:22 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332BA3A6981 for ; Tue, 10 Mar 2009 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lhZbBMHEsA1 for ; Tue, 10 Mar 2009 09:49:21 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 2E2F03A6967 for ; Tue, 10 Mar 2009 09:49:20 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with comcast id RNc81b00B1HzFnQ57UpwDr; Tue, 10 Mar 2009 16:49:56 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA14.westchester.pa.mail.comcast.net with comcast id RUpv1b00H4LCBKY3aUpv6L; Tue, 10 Mar 2009 16:49:56 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 12:49:55 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= , namedroppers@ops.ietf.org,dnsop@ietf.org From: Michael StJohns In-Reply-To: <200903100248.DAA07637@TR-Sys.de> References: <200903100248.DAA07637@TR-Sys.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090310164920.2E2F03A6967@core3.amsl.com> X-Mailman-Approved-At: Tue, 10 Mar 2009 11:15:57 -0700 Subject: Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 16:49:22 -0000 Hi Alfred - A better scheme for threshold signing for the root might be the Shoup paper: "Practical Threshold Signatures", Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99 The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. The Shoup system is only specified for RSA as far as I know. Mike At 10:48 PM 3/9/2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >This tools might be of interest for implementors of DNSSEC, >e.g. the folks wanting to distibute control over the future Root >Zone primary Key Signing Keys between the RIRs and ICANN/IANA. > >The new version should hopefully be ready for implementation. > > >----- Forwarded message from IETF I-D Submission Tool ----- > >> From: IETF I-D Submission Tool >> Message-Id: <20090309204424.AD5F73A687B@core3.amsl.com> >> Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) >> Subject: New Version Notification for draft-mcgrew-tss-02 > >A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly >submitted by David McGrew and posted to the IETF repository. > >Filename: draft-mcgrew-tss >Revision: 02 >Title: Threshold Secret Sharing >Creation_date: 2009-03-09 >WG ID: Independent Submission >Number_of_pages: 26 > >Abstract: >Threshold secret sharing (TSS) provides a way to generate N shares >from a value, so that any M of those shares can be used to >reconstruct the original value, but any M-1 shares provide no >information about that value. This method can provide shared access >control on key material and other secrets that must be strongly >protected. > >This note defines a threshold secret sharing method based on >polynomial interpolation in GF(256) and a format for the storage and >transmission of shares. It also provides usage guidance, describes >how to test an implementation, and supplies test cases. > > >The IETF Secretariat. > > >----- End of forwarded message from IETF I-D Submission Tool ----- > > >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 | >+------------------------+--------------------------------------------+ > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: From patrik@frobbit.se Tue Mar 10 11:31:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC11E3A6B0E for ; Tue, 10 Mar 2009 11:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mdkRv5zGg-z for ; Tue, 10 Mar 2009 11:31:15 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 5DC9E3A6B49 for ; Tue, 10 Mar 2009 11:31:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B2C52409A14D; Tue, 10 Mar 2009 19:31:20 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQV4pSpUsXVB; Tue, 10 Mar 2009 19:31:20 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 6F67C409A13F; Tue, 10 Mar 2009 19:31:20 +0100 (CET) Message-Id: <79B768FB-B486-4436-B43E-132922890732@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 19:31:20 +0100 References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:31:16 -0000 On 10 mar 2009, at 19.07, David Conrad wrote: > P.S. Out of curiosity, what is "=E4=B8=80" (Japanese Kanji for the = number =20 > 1) considered? U+4E00 : Lo, Other_Letter, L, Left_To_Right I.e. it is a letter. With strong directionality. So according to the =20 Unicode properties that we use so far, that is "not a number". Fun? Patrik From drc@virtualized.org Tue Mar 10 11:53:11 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD513A68ED for ; Tue, 10 Mar 2009 11:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.874 X-Spam-Level: X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wLeeysUbrA9 for ; Tue, 10 Mar 2009 11:53:11 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 3B49E3A6A8F for ; Tue, 10 Mar 2009 11:53:11 -0700 (PDT) Received: from [10.0.1.2] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 75F484ADC91; Tue, 10 Mar 2009 11:53:46 -0700 (PDT) Message-Id: From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <79B768FB-B486-4436-B43E-132922890732@frobbit.se> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 11:53:45 -0700 References: <20090309170441.GH16211@shinkuro.com> <1DFC713E-E45B-4664-AB1D-963A2C773C1F@virtualized.org> <57AB7362-2C4C-42B0-A934-BCA637D376C2@frobbit.se> <79B768FB-B486-4436-B43E-132922890732@frobbit.se> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:53:12 -0000 On Mar 10, 2009, at 11:31 AM, Patrik F=C3=A4ltstr=C3=B6m wrote: > On 10 mar 2009, at 19.07, David Conrad wrote: >> P.S. Out of curiosity, what is "=E4=B8=80" (Japanese Kanji for the = number =20 >> 1) considered? > U+4E00 : Lo, Other_Letter, L, Left_To_Right > I.e. it is a letter. With strong directionality. So according to the =20= > Unicode properties that we use so far, that is "not a number". > Fun? I'd say "interesting" (in the same way I find the Ebola virus =20 "interesting"). :-) Regards, -drc From Mark_Andrews@isc.org Tue Mar 10 14:19:34 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662853A694F for ; Tue, 10 Mar 2009 14:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2iaWeMOlWCU for ; Tue, 10 Mar 2009 14:19:33 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 7F6063A69A7 for ; Tue, 10 Mar 2009 14:19:33 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 4ECAE11404F; Tue, 10 Mar 2009 21:19:48 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 871F6E6079; Tue, 10 Mar 2009 21:19:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2ALJf0D096724; Wed, 11 Mar 2009 08:19:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> To: Edward Lewis From: Mark Andrews In-reply-to: Your message of "Tue, 10 Mar 2009 10:52:11 EDT." Date: Wed, 11 Mar 2009 08:19:41 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:19:34 -0000 In message , Edward Lewis writes: > At 8:35 +1100 3/10/09, Mark Andrews wrote: > > > This make DNSKEY a better manditory record to publish. > > While there's little empirical data on trust anchors to date, my > inclination is to whole-heartedly disagree with this statement. So > long as the DS record points to a unique DNSKEY record and the DS > record involves less typing than a DNSKEY, I'd want to work with a DS > record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.9999%) people would just cut-and-paste or the equivalent. I call "ease of typing" a unjustifiable justification as no one will be doing it even for DS records. I will agree that DNSKEY's are harder to compare, but I believe impossible trumps harder and it is impossible to convert a DS to a DNSKEY prior to the publication of the DNSKEY in the DNS. The reverse is not true. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Getting everything you want is easy if you don't want much. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From mlarson@verisign.com Tue Mar 10 14:36:09 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16DF3A6946 for ; Tue, 10 Mar 2009 14:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xblAo+Vj3Rg for ; Tue, 10 Mar 2009 14:36:09 -0700 (PDT) Received: from cliffie.verisignlabs.com (mail.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id E798A3A6907 for ; Tue, 10 Mar 2009 14:36:08 -0700 (PDT) Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 5D2F8136735; Tue, 10 Mar 2009 17:36:43 -0400 (EDT) Received: from dul1mcmlarson-l1.local (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 5250A242149; Tue, 10 Mar 2009 17:36:43 -0400 (EDT) Date: Tue, 10 Mar 2009 17:36:43 -0400 From: Matt Larson To: Mark Andrews Message-ID: <20090310213643.GN2727@dul1mcmlarson-l1.local> References: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:36:09 -0000 Mark, On Wed, 11 Mar 2009, Mark Andrews wrote: > [...] it is impossible to convert a DS to a DNSKEY prior to the > publication of the DNSKEY in the DNS. Why would a validator ever need to do this? Matt From wmaton@ryouko.imsb.nrc.ca Tue Mar 10 14:45:26 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AE43A693F for ; Tue, 10 Mar 2009 14:45:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39iAcxi3gjGv for ; Tue, 10 Mar 2009 14:45:25 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 07E323A6844 for ; Tue, 10 Mar 2009 14:45:24 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n2ALjsT3012316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Mar 2009 17:45:59 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n2ALjsvK012313 for ; Tue, 10 Mar 2009 17:45:54 -0400 Date: Tue, 10 Mar 2009 17:45:54 -0400 (EDT) From: "William F. Maton Sotomayor" To: dnsop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [DNSOP] Updates to AS 112 WG drafts X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:45:26 -0000 All, After somewhat of a longer hiatus on Peter's part (the WG last call on one document seems to have drifted by and then dropped) and my part (largely to do with increased workload), I have finally put together new versions of each draft. The proceeding is based on some correspondence between the ID authors and Peter relating to some issues that were left on the burner, so I wanted to summarize them here to add context. Many suggestions by volunteer reviewers had been incorporated into the help-help draft (and to a lesser extent the -ops draft) for revision 01 of each document. However, discussion traffic faded after their release. One comment on -help-help had been raised by Olafur, located here: http://www.ietf.org/mail-archive/web/dnsop/current/msg05601.html None of the versions of this draft address his comment, nor was there any discernable (at least in the archives) comment made on it by others on the WG list. I wanted to remind people about this one and see if the silence meant that there wasn't an issue after all. Next, there seemed to be no opposition in the working group meeting from March 2007 to have both of these go to WGLC: http://www.ietf.org/proceedings/07mar/minutes/dnsop.txt In the successive meeting, it looks like -help-help made it to WGLC: http://www.ietf.org/proceedings/07jul/minutes/dnsop.txt Then there's the issue of IPv6 transport which seems to be heading towards a separate draft. (I haven't asked about what happened to the LOA discussions for AS112, but that's off topic to this email.) In the Vancouver 2007 IETF, the -01 submissions were recognized: http://www.ietf.org/proceedings/07dec/minutes/dnsop.txt Anyways, the review trail picks up after that: -Mohsen Souissi pointed out Mark Andrews' draft on local zones was renamed. -Stephane Bortzmeyer was very keen that these drafts stated that we were documenting current practices. I think the intention was to leave the door wide open for a future ID on AS112 operations, aimed at addressing outstanding issues (maybe adding zones, IPv6 transport, DNSSEC, etc). -Stephane points out that there is no AS112 NOC contact in -help-help (http://www.ietf.org/mail-archive/web/dnsop/current/msg06006.html) -Andrew Sullivan around the same time made some additional comments on -ops: (http://www.ietf.org/mail-archive/web/dnsop/current/msg05973.html) Then it stops cold. Peter Koch then provided some very useful comments on -help-help-01. These are now rolled into 02. Otherwise the -02 versions have taken the above into account. Thanks, wfms From cet1@hermes.cam.ac.uk Tue Mar 10 15:00:46 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324B33A6A67 for ; Tue, 10 Mar 2009 15:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.205 X-Spam-Level: X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=1.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKAHkl9lp1-x for ; Tue, 10 Mar 2009 15:00:45 -0700 (PDT) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id 43EE63A6844 for ; Tue, 10 Mar 2009 15:00:45 -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]:45541) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1LhA0m-0000B9-Jf (Exim 4.70) for dnsop@ietf.org (return-path ); Tue, 10 Mar 2009 22:01:20 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1LhA0m-0007JP-2f (Exim 4.67) for dnsop@ietf.org (return-path ); Tue, 10 Mar 2009 22:01:20 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 10 Mar 2009 22:01:19 +0000 Date: 10 Mar 2009 22:01:19 +0000 From: Chris Thompson To: dnsop@ietf.org Message-ID: In-Reply-To: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> References: Your message of "Tue, 10 Mar 2009 10:52:11 EDT." <200903102119.n2ALJf0D096724@drugs.dv.isc.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dnsop@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:00:46 -0000 On Mar 10 2009, Mark Andrews wrote: > Has anyone on this list ever typed in a DNSKEY or DS as a > trust anchor? I would presume that most (99.9999%) people > would just cut-and-paste or the equivalent. I call "ease > of typing" a unjustifiable justification as no one will be > doing it even for DS records. I have to agree with that, except that you probably need more 9's. > I will agree that DNSKEY's are harder to compare, but I > believe impossible trumps harder and it is impossible to > convert a DS to a DNSKEY prior to the publication of the > DNSKEY in the DNS. The reverse is not true. But that's exactly seen as a benefit in section 2 of draft-ietf-dnsop-dnssec-trust-anchor ("forces priming") and in previous posts here ("does not expose the KSK to factorisation attacks during the pre-publication period"). You may consider these nugatory benefits, but perhaps you should say why. I admit to a prejudice in favour of DS-shaped trust anchors, really based on the concept that a trust anchor should be a certificate "in loco parentis". It fits in with my favourite spiel about how the root hints "zone" is actually the referral from Trantor, kept locally only because the RTT to Trantor is too damn long. On that basis, the trust anchor for the root zone ought to be the DS record from Trantor. -- Chris Thompson Email: cet1@cam.ac.uk From Mark_Andrews@isc.org Tue Mar 10 15:13:48 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BEE3A67ED for ; Tue, 10 Mar 2009 15:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUFgIS1g49YC for ; Tue, 10 Mar 2009 15:13:48 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 1D2AD3A67F0 for ; Tue, 10 Mar 2009 15:13:48 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id D3DB611401C; Tue, 10 Mar 2009 22:14:20 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 03EBDE6079; Tue, 10 Mar 2009 22:14:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2AMEEmL097525; Wed, 11 Mar 2009 09:14:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903102214.n2AMEEmL097525@drugs.dv.isc.org> To: Matt Larson From: Mark Andrews In-reply-to: Your message of "Tue, 10 Mar 2009 17:36:43 EDT." <20090310213643.GN2727@dul1mcmlarson-l1.local> Date: Wed, 11 Mar 2009 09:14:14 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:13:49 -0000 In message <20090310213643.GN2727@dul1mcmlarson-l1.local>, Matt Larson writes: > Mark, > > On Wed, 11 Mar 2009, Mark Andrews wrote: > > [...] it is impossible to convert a DS to a DNSKEY prior to the > > publication of the DNSKEY in the DNS. > > Why would a validator ever need to do this? Because it makes it possible to change DNSKEYs without having to have both the old and new key present in the zone at the same time. > Matt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From mlarson@verisign.com Tue Mar 10 16:21:42 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C233A6881 for ; Tue, 10 Mar 2009 16:21:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqAnoAje+oJS for ; Tue, 10 Mar 2009 16:21:41 -0700 (PDT) Received: from mail.kahlerlarson.org (tornado.kahlerlarson.org [64.22.125.99]) by core3.amsl.com (Postfix) with ESMTP id D30303A6781 for ; Tue, 10 Mar 2009 16:21:41 -0700 (PDT) Received: from sirocco.local (pool-71-191-133-211.washdc.fios.verizon.net [71.191.133.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id 7F86137CF0; Tue, 10 Mar 2009 19:22:16 -0400 (EDT) Date: Tue, 10 Mar 2009 19:22:16 -0400 From: Matt Larson To: Mark Andrews Message-ID: <20090310232216.GC3104@sirocco.local> References: <20090310213643.GN2727@dul1mcmlarson-l1.local> <200903102214.n2AMEEmL097525@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903102214.n2AMEEmL097525@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 23:21:42 -0000 On Wed, 11 Mar 2009, Mark Andrews wrote: > > In message <20090310213643.GN2727@dul1mcmlarson-l1.local>, Matt Larson writes: > > Mark, > > > > On Wed, 11 Mar 2009, Mark Andrews wrote: > > > [...] it is impossible to convert a DS to a DNSKEY prior to the > > > publication of the DNSKEY in the DNS. > > > > Why would a validator ever need to do this? > > Because it makes it possible to change DNSKEYs without > having to have both the old and new key present in the zone > at the same time. I don't see it. Please explain further. Matt From Mark_Andrews@isc.org Tue Mar 10 16:40:34 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5643A6A2A for ; Tue, 10 Mar 2009 16:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSwx85ogEVPq for ; Tue, 10 Mar 2009 16:40:33 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 383873A67DD for ; Tue, 10 Mar 2009 16:40:33 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id D77C511402B; Tue, 10 Mar 2009 23:41:02 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 58FCBE6064; Tue, 10 Mar 2009 23:41:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2ANex6S004074; Wed, 11 Mar 2009 10:40:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903102340.n2ANex6S004074@drugs.dv.isc.org> To: Matt Larson From: Mark Andrews In-reply-to: Your message of "Tue, 10 Mar 2009 19:22:16 EDT." <20090310232216.GC3104@sirocco.local> Date: Wed, 11 Mar 2009 10:40:59 +1100 Sender: Mark_Andrews@isc.org Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 23:40:34 -0000 In message <20090310232216.GC3104@sirocco.local>, Matt Larson writes: > On Wed, 11 Mar 2009, Mark Andrews wrote: > > > > In message <20090310213643.GN2727@dul1mcmlarson-l1.local>, Matt Larson writ > es: > > > Mark, > > > > > > On Wed, 11 Mar 2009, Mark Andrews wrote: > > > > [...] it is impossible to convert a DS to a DNSKEY prior to the > > > > publication of the DNSKEY in the DNS. > > > > > > Why would a validator ever need to do this? > > > > Because it makes it possible to change DNSKEYs without > > having to have both the old and new key present in the zone > > at the same time. > > I don't see it. Please explain further. > > Matt I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From bmanning@karoshi.com Tue Mar 10 19:49:00 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020E23A6AD5 for ; Tue, 10 Mar 2009 19:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckzd01Ru6Nn3 for ; Tue, 10 Mar 2009 19:48:59 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id EF4423A69BF for ; Tue, 10 Mar 2009 19:48:58 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n2B2nVff013314; Wed, 11 Mar 2009 02:49:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n2B2nSHF013313; Wed, 11 Mar 2009 02:49:28 GMT Date: Wed, 11 Mar 2009 02:49:28 +0000 From: bmanning@vacation.karoshi.com To: Michael StJohns Message-ID: <20090311024928.GA13301@vacation.karoshi.com.> References: <200903100248.DAA07637@TR-Sys.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: namedroppers@ops.ietf.org, Alfred =?iso-8859-1?Q?H=F6nes?= , dnsop@ietf.org Subject: Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 02:49:00 -0000 I really like the Shoup paper. But I've not seen too many implementations in the wild. :) --bill On Tue, Mar 10, 2009 at 12:49:55PM -0400, Michael StJohns wrote: > Hi Alfred - > > A better scheme for threshold signing for the root might be the Shoup paper: "Practical Threshold Signatures", Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99 > > The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. > > Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. > > The Shoup system is only specified for RSA as far as I know. > > Mike > > > > At 10:48 PM 3/9/2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: > >This tools might be of interest for implementors of DNSSEC, > >e.g. the folks wanting to distibute control over the future Root > >Zone primary Key Signing Keys between the RIRs and ICANN/IANA. > > > >The new version should hopefully be ready for implementation. > > > > > >----- Forwarded message from IETF I-D Submission Tool ----- > > > >> From: IETF I-D Submission Tool > >> Message-Id: <20090309204424.AD5F73A687B@core3.amsl.com> > >> Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) > >> Subject: New Version Notification for draft-mcgrew-tss-02 > > > >A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly > >submitted by David McGrew and posted to the IETF repository. > > > >Filename: draft-mcgrew-tss > >Revision: 02 > >Title: Threshold Secret Sharing > >Creation_date: 2009-03-09 > >WG ID: Independent Submission > >Number_of_pages: 26 > > > >Abstract: > >Threshold secret sharing (TSS) provides a way to generate N shares > >from a value, so that any M of those shares can be used to > >reconstruct the original value, but any M-1 shares provide no > >information about that value. This method can provide shared access > >control on key material and other secrets that must be strongly > >protected. > > > >This note defines a threshold secret sharing method based on > >polynomial interpolation in GF(256) and a format for the storage and > >transmission of shares. It also provides usage guidance, describes > >how to test an implementation, and supplies test cases. > > > > > >The IETF Secretariat. > > > > > >----- End of forwarded message from IETF I-D Submission Tool ----- > > > > > >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 | > >+------------------------+--------------------------------------------+ > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: From mstjohns@comcast.net Tue Mar 10 20:35:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04543A6825 for ; Tue, 10 Mar 2009 20:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUIdq8gIhbpn for ; Tue, 10 Mar 2009 20:35:14 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id B17533A6833 for ; Tue, 10 Mar 2009 20:35:14 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Rf1k1b0060cZkys55fbrYv; Wed, 11 Mar 2009 03:35:51 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Rfbq1b00E4LCBKY3Wfbqru; Wed, 11 Mar 2009 03:35:51 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 23:35:50 -0400 To: bmanning@vacation.karoshi.com From: Michael StJohns In-Reply-To: <20090311024928.GA13301@vacation.karoshi.com.> References: <200903100248.DAA07637@TR-Sys.de> <20090311024928.GA13301@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090311033514.B17533A6833@core3.amsl.com> X-Mailman-Approved-At: Wed, 11 Mar 2009 01:02:48 -0700 Cc: namedroppers@ops.ietf.org, Alfred =?iso-8859-1?Q?H=F6nes?= , dnsop@ietf.org Subject: Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:35:16 -0000 I've got one. I modified an implementation of Shoup by Steve Weis which does raw RSA sigs to do PKCS1-v1.5 RSA signatures and from those to do DNSSEC signing. It allows the generation and wrapping of shares under remotely generated public keys - e.g. share holder public keys. When signatures are required, the data to be signed is sent to the share holders who decrypt their share with their private key, do a partial signature and return the signature share to the central location (or post it to a mailing list :-) ). The zone manager combines the partial signatures into a DNSSEC formatted RRSIG, verifies the signature is correct across the RRSet and then publishes it. Let me see if I can get permission to distribute it. Hmm.. looks like he's posted the underlying libraries. See http://code.google.com/p/threshsig/updates/list Mike At 10:49 PM 3/10/2009, bmanning@vacation.karoshi.com wrote: > I really like the Shoup paper. But I've not seen too many implementations in the wild. :) > >--bill > > >On Tue, Mar 10, 2009 at 12:49:55PM -0400, Michael StJohns wrote: >> Hi Alfred - >> >> A better scheme for threshold signing for the root might be the Shoup paper: "Practical Threshold Signatures", Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99 >> >> The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. >> >> Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. >> >> The Shoup system is only specified for RSA as far as I know. >> >> Mike >> >> >> >> At 10:48 PM 3/9/2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >> >This tools might be of interest for implementors of DNSSEC, >> >e.g. the folks wanting to distibute control over the future Root >> >Zone primary Key Signing Keys between the RIRs and ICANN/IANA. >> > >> >The new version should hopefully be ready for implementation. >> > >> > >> >----- Forwarded message from IETF I-D Submission Tool ----- >> > >> >> From: IETF I-D Submission Tool >> >> Message-Id: <20090309204424.AD5F73A687B@core3.amsl.com> >> >> Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) >> >> Subject: New Version Notification for draft-mcgrew-tss-02 >> > >> >A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly >> >submitted by David McGrew and posted to the IETF repository. >> > >> >Filename: draft-mcgrew-tss >> >Revision: 02 >> >Title: Threshold Secret Sharing >> >Creation_date: 2009-03-09 >> >WG ID: Independent Submission >> >Number_of_pages: 26 >> > >> >Abstract: >> >Threshold secret sharing (TSS) provides a way to generate N shares >> >from a value, so that any M of those shares can be used to >> >reconstruct the original value, but any M-1 shares provide no >> >information about that value. This method can provide shared access >> >control on key material and other secrets that must be strongly >> >protected. >> > >> >This note defines a threshold secret sharing method based on >> >polynomial interpolation in GF(256) and a format for the storage and >> >transmission of shares. It also provides usage guidance, describes >> >how to test an implementation, and supplies test cases. >> > >> > >> >The IETF Secretariat. >> > >> > >> >----- End of forwarded message from IETF I-D Submission Tool ----- >> > >> > >> >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 | >> >+------------------------+--------------------------------------------+ >> > >> > >> >-- >> >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> >the word 'unsubscribe' in a single line as the message text body. >> >archive: >> >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: From Ray.Bellis@nominet.org.uk Wed Mar 11 01:25:45 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CA43A696D for ; Wed, 11 Mar 2009 01:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmUkMvLTlcOR for ; Wed, 11 Mar 2009 01:25:45 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B0EFF3A67A1 for ; Wed, 11 Mar 2009 01:25:44 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=EsEp99IwJ96oyGgU3JjnuoyOTokVtT1dSv6z99KUcg4SPM+iGIdODzuQ rfocUi8BwcTVwki23Kb4X+IVnO4UE64bC3vUN5INiG8W1KdcbCIKJA33N rP+CMf/tSYZ7t0N; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1236759981; x=1268295981; 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:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[DNSO P]=20Truncation=20discussion=09in=09draft-ietf-dnsop-dnss ec-trust-anchor-02|Date:=20Wed,=2011=20Mar=202009=2008:26 :17=20+0000|Message-ID:=20|To:=20dnsop@i etf.org|MIME-Version:=201.0|In-Reply-To:=20|References: =20Your=20message=20of=20"Tue,=2010=20Mar=202009=2010:52: 11=20EDT."=09=0D =0A=09<200903102119.n2ALJf0D096724@drugs.dv.isc.org>=20

; bh=Y6sAOrawFBIBbvBvTrxXlUWxsZhIpOoIJCa4PpuZhH4=; b=M50bewIRwUwHuyHipg9kDOop2GYg4+5bSeA/P6CibrekCzNix52Pxe+L NXru0tno5PQnrxYYMtUwKcO+CsMCEjkSI/ino5NjWHkRmkeWF7wDsIGQ9 jAL24giCAmgpzjj; X-IronPort-AV: E=Sophos;i="4.38,341,1233532800"; d="scan'208";a="8903990" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 11 Mar 2009 08:26:19 +0000 In-Reply-To: References: Your message of "Tue, 10 Mar 2009 10:52:11 EDT." <200903102119.n2ALJf0D096724@drugs.dv.isc.org> To: dnsop@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 11 Mar 2009 08:26:17 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/03/2009 08:26:19 AM, Serialize complete at 11/03/2009 08:26:19 AM Content-Type: text/plain; charset="US-ASCII" Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 08:25:46 -0000 > I have to agree with that, except that you probably need more 9's. Oh, I don't know about that. Three 9's should be more than enough accuracy to describe the set of people who've ever put a DS or DNSKEY record in their zone files ;-) Ray From ajs@shinkuro.com Wed Mar 11 06:45:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237C93A6942 for ; Wed, 11 Mar 2009 06:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mEW2tBXTjuy for ; Wed, 11 Mar 2009 06:45:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5C4AD3A6823 for ; Wed, 11 Mar 2009 06:45:14 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 663F12FEA4F4 for ; Wed, 11 Mar 2009 13:45:49 +0000 (UTC) Date: Wed, 11 Mar 2009 09:45:46 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090311134546.GA18975@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090310092721.GA631@nic.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:45:15 -0000 On Tue, Mar 10, 2009 at 10:27:21AM +0100, Stephane Bortzmeyer wrote: > recollection of one specific person. The "alphabetic-only" rule in RFC > 1123 is just a side note, never detailed, and presented as a fact > (which it was at this time), not as a mandatory restriction. I don't know whether I agree that it's just a "side note". It seems to be a clarifying discussion used to explain why an innovation is safe. As we have seen in the current discussion, there is possibly more than one interpretation of that safety. I think that's what we have to consider. > There are no *TECHNICAL* reasons to limit TLD to alphabetic > characters. I think this is what's up for dispute. If people have interpreted the text in 1123 as normative and built resolvers using the logic there, then that is a technical reason to limit TLD characters. Even if we think those resolvers were mistaken in their implementation, they're deployed. Interoperation is one of our more important values, and that includes interoperation with reasonable interpretations of RFCs that we nevertheless think are mistaken. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From mlarson@verisign.com Wed Mar 11 07:07:34 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23AC3A69D0 for ; Wed, 11 Mar 2009 07:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs5PjrfwXaSe for ; Wed, 11 Mar 2009 07:07:29 -0700 (PDT) Received: from cliffie.verisignlabs.com (mail.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id 5FCE628C11A for ; Wed, 11 Mar 2009 07:07:29 -0700 (PDT) Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id BF018136714 for ; Wed, 11 Mar 2009 10:08:04 -0400 (EDT) Received: from dul1mcmlarson-l1.local (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id B759B24234C for ; Wed, 11 Mar 2009 10:08:04 -0400 (EDT) Date: Wed, 11 Mar 2009 10:08:04 -0400 From: Matt Larson To: IETF DNSOP WG Message-ID: <20090311140804.GU2727@dul1mcmlarson-l1.local> References: <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:07:34 -0000 On Sat, 07 Mar 2009, Patrik Fltstrm wrote: > Will there also be a problem with digits within a label? "Probably > not", but I rather see a generic good definition of "the gray area" > and who is responsible for arguing (I an not saying proving here) > whether something is "ok to delegate" or not, and I think it should > be the applicant that argue it is ok. Not the other way around. Patrik, are you suggesting that a TLD label with interior digits (but not beginning or ending the TLD label) should be disallowed? Or are you suggesting that anyone proposing a such a TLD with an interior digit should prove no harm? Or something else? Could someone please give a concrete example of why a digit within a TLD label would be a problem? I grudgingly accept that the idea of digits starting or ending a TLD label needs further discussion, but I cannot be convinced about a prohibition against digits within a TLD label without some justification. Matt From patrik@frobbit.se Wed Mar 11 07:51:39 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667173A6A29 for ; Wed, 11 Mar 2009 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU-yPWa-KG0f for ; Wed, 11 Mar 2009 07:51:35 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 74B113A679F for ; Wed, 11 Mar 2009 07:51:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id AEED640D5E43; Wed, 11 Mar 2009 15:52:10 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80LMmcBHsfDK; Wed, 11 Mar 2009 15:52:09 +0100 (CET) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 331E840D5E38; Wed, 11 Mar 2009 15:52:09 +0100 (CET) Message-Id: <7400BC4A-6292-434C-9021-C9E0C9402B6E@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Matt Larson In-Reply-To: <20090311140804.GU2727@dul1mcmlarson-l1.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 15:52:08 +0100 References: <20090306095645.GA19005@nic.fr> <20090306190855.GL12711@shinkuro.com> <20090306201347.GO12711@shinkuro.com> <61CCA7BB-4DD0-4C09-87C4-7BE9F962DE6B@virtualized.org> <6EE9E406-23F6-40ED-ADA2-0A90323D33CC@frobbit.se> <20090311140804.GU2727@dul1mcmlarson-l1.local> X-Mailer: Apple Mail (2.930.3) Cc: IETF DNSOP WG Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:51:39 -0000 On 11 mar 2009, at 15.08, Matt Larson wrote: > On Sat, 07 Mar 2009, Patrik Fltstrm wrote: >> Will there also be a problem with digits within a label? "Probably >> not", but I rather see a generic good definition of "the gray area" >> and who is responsible for arguing (I an not saying proving here) >> whether something is "ok to delegate" or not, and I think it should >> be the applicant that argue it is ok. Not the other way around. > > Patrik, are you suggesting that a TLD label with interior digits (but > not beginning or ending the TLD label) should be disallowed? > > Or are you suggesting that anyone proposing a such a TLD with an > interior digit should prove no harm? > > Or something else? > > Could someone please give a concrete example of why a digit within a > TLD label would be a problem? I grudgingly accept that the idea of > digits starting or ending a TLD label needs further discussion, but I > cannot be convinced about a prohibition against digits within a TLD > label without some justification. I think, with my compared to some people limited knowledge about Unicode, think that IF the first and last character of a TLD do have what is called strong, and the same, directionality, then it does NOT matter what is _inside_ the label. Note that I am not using terminology like "digit" or "alphabetic" now, and that is intentional. I am just looking at the characteristics of the Unicode codepoints. Patrik From james.seng@gmail.com Wed Mar 11 07:55:36 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023C63A69FA for ; Wed, 11 Mar 2009 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUOBUuce6ih5 for ; Wed, 11 Mar 2009 07:55:35 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 16DDD3A6810 for ; Wed, 11 Mar 2009 07:55:34 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so18416tim.25 for ; Wed, 11 Mar 2009 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5g8lAwNnFZB1C9WT0sFvm1p96hl+GOvtB46TclhQHss=; b=ogVq4wujCpYuT/dbZvlu18X1f8QbQOhpksquNCLqRls7ly6jV/AqNRz9FnRCeazFQU Tbj7P9X6D4Mx6nIqaczUrROoqB15eqUF6ERFkHcDsNsHK/DfnrZY7hZqjh93faqE9iiN itG7RNuqj7zimpSzGnB9FIFvVP0+myM4hfVis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t4cf5qVj3xT4fq2pi0fVCZAPV7WrJHal95ALooRYV4LOKCwd942TsTvQBkpcxYwzac GZmdh4mDZ2GqKYyEpZNlAy5pZaQP3hnCELa/cczN9knZ4/jDws3xBz/X76rv99c2RxXm bvXGgh0IG8txTWoG6J2zy7SOjbTxdVnFWV2Lo= MIME-Version: 1.0 Sender: james.seng@gmail.com Received: by 10.110.50.19 with SMTP id x19mr13058137tix.19.1236783370737; Wed, 11 Mar 2009 07:56:10 -0700 (PDT) In-Reply-To: <20090311134546.GA18975@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> <20090311134546.GA18975@shinkuro.com> Date: Wed, 11 Mar 2009 22:56:10 +0800 X-Google-Sender-Auth: 6b55bcece8f0c3c1 Message-ID: <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> From: James Seng To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:55:36 -0000 By the same logic, the whole IDN would be pointless because RFC 1035 restrict labels to "alphabetic letter" only. IDNA transform IDN labels into punycode so that it become transparent to the resolvers who made those assumption. -James Seng > I think this is what's up for dispute. =C2=A0If people have interpreted t= he > text in 1123 as normative and built resolvers using the logic there, > then that is a technical reason to limit TLD characters. =C2=A0Even if we > think those resolvers were mistaken in their implementation, they're > deployed. =C2=A0Interoperation is one of our more important values, and > that includes interoperation with reasonable interpretations of RFCs > that we nevertheless think are mistaken. > > Best, > > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From Ed.Lewis@neustar.biz Wed Mar 11 07:58:38 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D329B3A68E6 for ; Wed, 11 Mar 2009 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID1YwfMM+nZz for ; Wed, 11 Mar 2009 07:58:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D62A23A679C for ; Wed, 11 Mar 2009 07:58:32 -0700 (PDT) Received: from [10.31.200.116] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n2BEx0HY084609; Wed, 11 Mar 2009 10:59:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> References: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> Date: Wed, 11 Mar 2009 10:57:31 -0400 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: Edward Lewis Subject: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:58:38 -0000 At 8:19 +1100 3/11/09, Mark Andrews wrote: >In message , Edward Lewis writes: >> record involves less typing than a DNSKEY, I'd want to work with a DS >> record. > > Has anyone on this list ever typed in a DNSKEY or DS as a > trust anchor? I would presume that most (99.9999%) people "work with" != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: > I have a new key I want to introduce. I add the DS to the > parent zone at least the ttl(ds) before I start using that > key in the zone. After the DS has been published for ttl(ds) > I can then replace the DNSKEY referred to by the old DS > with that of the new DS and re-sign the DNSKEY RRset. Once > the ttl(dnskey) has expired I can remove the old DS from > the parent zone. > > I wish to be able to do something similar with trust anchors. > Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed "by the 15th." On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are "tied" to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if "for a DS record there is no corresponding DNSKEY" and vice versa. All that is needed for validation is one "chain of trust." Accepting dangling references is not optimal but provides robustness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. From bortzmeyer@nic.fr Wed Mar 11 08:28:27 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E0A3A69CC for ; Wed, 11 Mar 2009 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=1.792, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdILN5zHjurX for ; Wed, 11 Mar 2009 08:28:22 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 254F33A69C4 for ; Wed, 11 Mar 2009 08:28:22 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5119D1C010B; Wed, 11 Mar 2009 16:23:57 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4B2C81C00D3; Wed, 11 Mar 2009 16:23:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3F41D7B0030; Wed, 11 Mar 2009 16:23:57 +0100 (CET) Date: Wed, 11 Mar 2009 16:23:57 +0100 From: Stephane Bortzmeyer To: James Seng Message-ID: <20090311152357.GA18153@nic.fr> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> <20090311134546.GA18975@shinkuro.com> <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:28:27 -0000 On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote a message of 4 lines which said: > By the same logic, the whole IDN would be pointless because RFC > 1035restrict labels to "alphabetic letter" only. I assume you're playing the devil's advocate? Because I believe that all dnsop members know that the reason why we need IDN is not the inability of the DNS to handle 8-bits characters... From ajs@shinkuro.com Wed Mar 11 08:36:18 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C810E3A6A42 for ; Wed, 11 Mar 2009 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=1.259, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXIgC4abB9yK for ; Wed, 11 Mar 2009 08:36:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id ED38D3A696A for ; Wed, 11 Mar 2009 08:36:17 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BEBAD2FEA4F4 for ; Wed, 11 Mar 2009 15:36:53 +0000 (UTC) Date: Wed, 11 Mar 2009 11:36:52 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090311153651.GG18975@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> <20090311134546.GA18975@shinkuro.com> <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:36:18 -0000 On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote: > By the same logic, the whole IDN would be pointless because RFC 1035 > restrict labels to "alphabetic letter" only. I'd like the reference to where 1035 says that, please. In particular, the following passage in §3.1 of RFC 1035 seems to say something different: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. In addition, > IDNA transform IDN labels into punycode so that it become transparent > to the resolvers who made those assumption. you seem to be making my argument for me. The reason IDNA is preferable to some of the alternatives is that some resolver software indeed understood 1034 and 1035 to mean that the "preferred syntax" ought to be enforced (in what seems to me a plain violation of those RFCs). We have to live with those widely-deployed resolvers, and therefore we need to design other protocols as though the additional restrictions that are _not_ part of the DNS protocol are in fact part of it. Designing the protocols for the actually existing conditions in the network is what makes the design activity "engineering" rather than "research", I think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From james.seng@gmail.com Wed Mar 11 08:44:21 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BAA3A6B68 for ; Wed, 11 Mar 2009 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn+oVizEEX5z for ; Wed, 11 Mar 2009 08:44:20 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id E41443A6B05 for ; Wed, 11 Mar 2009 08:44:19 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so28632tim.25 for ; Wed, 11 Mar 2009 08:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=liBNpIQK2gY+sYP6+QlZeS9k1qMUgS3CjjUsbXCdphs=; b=X+OqxsVNDwemDXruyutyOQobWlMMVCMHFI2tbYeTBqx+j0v74WjareQouK4Y8Y4ZU1 HEQDdZoHDch1rkC4Ght2hytSkv6br5+n7emvODlvpZcjnF6zmGo+gHTBSby9HUETsE3I EV47r4fR0xxE9wAGxbResA4+Gp0874wfOM8Qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v6Upf1Y0Tdx34Sca2be9AJW/u9DvfauG2ZQe+VX9TyMPssFmVmVbT2wtZAzFpHEbk+ Nq3oWKE8UJhP1tb+jKA8MNMtPuIwnawHvlyurKHBZZHiSw/GFSofNocmJvd92KhsZw1M QKHjq1fgvhV5IPFrMnA2ELv/Hzet0k+69WWZs= MIME-Version: 1.0 Sender: james.seng@gmail.com Received: by 10.110.62.1 with SMTP id k1mr13109786tia.38.1236786295051; Wed, 11 Mar 2009 08:44:55 -0700 (PDT) In-Reply-To: <20090311153651.GG18975@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> <20090311134546.GA18975@shinkuro.com> <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> <20090311153651.GG18975@shinkuro.com> Date: Wed, 11 Mar 2009 23:44:54 +0800 X-Google-Sender-Auth: 963e7954e75be0ba Message-ID: <558a39a60903110844y3d448bb5pf5b366a5465c7ef0@mail.gmail.com> From: James Seng To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:44:21 -0000 On Wed, Mar 11, 2009 at 11:36 PM, Andrew Sullivan wrote: > On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote: >> By the same logic, the whole IDN would be pointless because RFC 1035 >> restrict labels to "alphabetic letter" only. > > I'd like the reference to where 1035 says that, please. =C2=A0In > particular, the following passage in =C2=A73.1 of RFC 1035 seems to say > something different:

On Wed, Mar 11, 2009 at 10:5= 7 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:
At 8:19 +1100 3/1= 1/09, Mark Andrews wrote:
In message <a06240804c5dc2ddef171@[10.31.200.116]>, Edward Lewis writ= es:

=A0record involves less typing than a DNSKEY, I'd want to work with a D= S
=A0record.

=A0 =A0 =A0 =A0Has anyone on this list ever typed in a DNSKEY or DS as a =A0 =A0 =A0 =A0trust anchor? =A0I would presume that most (99.9999%) peopl= e

"work with" !=3D type in

At 10:40 +1100 3/11/09, Mark Andrews wrote:
=A0 =A0 =A0 =A0I have a new key I want to introduce. =A0I add the DS to th= e
=A0 =A0 =A0 =A0parent zone at least the ttl(ds) before I start using that<= br> =A0 =A0 =A0 =A0key in the zone. =A0After the DS has been published for ttl= (ds)
=A0 =A0 =A0 =A0I can then replace the DNSKEY referred to by the old DS
=A0 =A0 =A0 =A0with that of the new DS and re-sign the DNSKEY RRset. =A0On= ce
=A0 =A0 =A0 =A0the ttl(dnskey) has expired I can remove the old DS from =A0 =A0 =A0 =A0the parent zone.

=A0 =A0 =A0 =A0I wish to be able to do something similar with trust anchor= s.
=A0 =A0 =A0 =A0Publishing DS prevents me from doing so.

There is more than one way to do a key supersession. =A0I'll describe o= ne assuming DS records are installed as trust anchors.

DS(KEY1) is in my validator. =A0The owner of KEY1 distributes DS(KEY2) with= a note that it should be installed "by the 15th." =A0On the 15th= , DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keys= et. =A0With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY= (KEY1) is removed from the set. =A0At some point after that I can remove DS= (KEY1) from my validator.

Perhaps the special case here is that the keyset is unique in that the sign= atures for SEP/KSK's are "tied" to the where the key data is.= I.e., if you have something signed by KEY1, then you have KEY1 because tha= t something has to be the key set.

If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is tr= iggered by signing the last RR set by KEY2 and then the TTL.

The principle here is that there is no error if "for a DS record there= is no corresponding DNSKEY" and vice versa. =A0All that is needed for= validation is one "chain of trust." =A0Accepting dangling refere= nces is not optimal but provides robustness.

--
-=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-=3D-=3D= -
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop



--
Joe Baptista
www.publicroot.org
PublicRoot Consort= ium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative = & Accountable to the Internet community @large.
--------------------= --------------------------------------------
=A0Office: +1 (360) 526-60= 77 (extension 052)
=A0 =A0 Fax: +1 (509) 479-0084

--0016363108cd99c6180464e0d145-- From Mark_Andrews@isc.org Wed Mar 11 17:10:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E080E3A6AFE for ; Wed, 11 Mar 2009 17:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViYSY18sYWwK for ; Wed, 11 Mar 2009 17:10:36 -0700 (PDT) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id D98CF3A69BC for ; Wed, 11 Mar 2009 17:10:35 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id A696311402C; Thu, 12 Mar 2009 00:11:00 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0629EE6074; Thu, 12 Mar 2009 00:10:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n2C0AvbS024272; Thu, 12 Mar 2009 11:10:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200903120010.n2C0AvbS024272@drugs.dv.isc.org> To: James Seng From: Mark Andrews In-reply-to: Your message of "Thu, 12 Mar 2009 00:07:47 +0800." <558a39a60903110907i6edad88dye59293cbac951c5d@mail.gmail.com> Date: Thu, 12 Mar 2009 11:10:57 +1100 Sender: Mark_Andrews@isc.org Cc: IETF DNSOP WG Subject: Re: [DNSOP] RFC1035 and permitted characters in labels X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 00:10:38 -0000 In message <558a39a60903110907i6edad88dye59293cbac951c5d@mail.gmail.com>, James Seng writes: > Agreed :) > > DNS is suppose to be 8-bit clean as according to RFC 1035. No it is supposed to be nearly 8 bit clean. :-) > But taken in context with that recommended section in RFC 1035, together with > RFC 952, many legacy implementation already assumed DNS must be LDH. > By the time RFC 2181 comes along, it was too late. > > This was one of the reasons why Punycode was chosen and not UTF-8 for IDN. > > -James Seng RFC 952 is for HOST NAMES RFC 1035 is for DOMAIN NAMES. Host names and domain names are DIFFERENT things and are often confused in the RFC's. Punycode was choosen because the hostname lookup components of resolvers and other components in applications enforce LDH for HOST NAME lookups (forward and reverse) and for MX lookups. Other sorts of lookups were not constrained. Host names and mail domains restrictions come from outside of the DNS. IDNA sits on top of RFC 952 (modified by RFC 1123) which sits on top of the DNS. > > Er, that's in Section 2.3.1: Preferred Name Syntax which says before the > > BNF: > > > > "The following syntax will result in fewer problems with many > > applications that use domain names" > > > > RFC1035 does not say that labels can only be composed of ASCII letters and > > digits. RFC1123 imposes limitations on the characters permissible in a host > > name. But that's not the same as a domain name. > > > > > > PS Apologies for changing the Subject: header into something appropriate. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From denic@eng.colt.net Wed Mar 11 17:40:15 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF963A67D4 for ; Wed, 11 Mar 2009 17:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=1.685, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q26UMGA76HpD for ; Wed, 11 Mar 2009 17:40:14 -0700 (PDT) Received: from smtp.lon.dcn.colt.net (smtp.lon.server.colt.net [212.74.77.49]) by core3.amsl.com (Postfix) with ESMTP id 95D0F3A6941 for ; Wed, 11 Mar 2009 17:40:14 -0700 (PDT) Received: from [194.45.79.6] (quo.fra.ws.colt.net [212.74.79.242]) by smtp.lon.dcn.colt.net (Postfix) with ESMTP id 684313587F; Thu, 12 Mar 2009 01:40:50 +0100 (CET) From: Ralf Weber To: Joe Baptista In-Reply-To: <874c02a20903111710o211bc7eaw5b2821a4914d29b4@mail.gmail.com> References: <200903102119.n2ALJf0D096724@drugs.dv.isc.org> <874c02a20903111710o211bc7eaw5b2821a4914d29b4@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 01:40:49 +0100 X-Mailer: Apple Mail (2.930.3) Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 00:40:15 -0000 Moin! On 12.03.2009, at 01:10, Joe Baptista wrote: > You poor souls. The DNSSEC monster is vast and complex. So much =20 > easier just to fix the problem instead of this endless gibberish. =20 > It's so complex it's funny when you consider a simple solution like =20= > DNSCURVE -http://dnscurve.org/ - and so much more secure. No man in =20= > the middle issues. DNSCurve solves a different problem. It's about encryption of DNS =20 data, while DNSSEC looks on authentication of DNS data. DNSSEC and =20 DNSCurve are complementary solutions not contradicting solutions. > Oh well - sorry for the interruption - and carry on. Ahem could I ask why you are carrying my companies logo on your =20 webpage? If there is an contractual relationship please send me the =20 details off list, otherwise please remove it. On the topic DNSKEY or DS keys as trust anchors I would opt for =20 DNSKEYS as there may be publication of trust anchors that may have =20 hash/digest algorithms that my resolver/validator doesn't understand. =20= This already happened to me :-(. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Sch=FCtze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra=DFe 4, 60528 Frankfurt/Main, Deutschland =20= * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch=E4ftsf=FChrer: Dr. J=FCrgen Hernichel (Vors.), Rita Thies * =20 Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From A.Hoenes@tr-sys.de Thu Mar 12 05:54:37 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF803A692A for ; Thu, 12 Mar 2009 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAc34+qtmza0 for ; Thu, 12 Mar 2009 05:54:32 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E7CAB3A685C for ; Thu, 12 Mar 2009 05:54:30 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA276562392; Thu, 12 Mar 2009 13:53:12 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA12899 for dnsop@ietf.org; Thu, 12 Mar 2009 13:53:12 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903121253.NAA12899@TR-Sys.de> To: dnsop@ietf.org Date: Thu, 12 Mar 2009 13:53:11 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [DNSOP] Updates to AS 112 WG drafts -- solicitation for progress X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 12:54:37 -0000 Hello all, First, my thanks to William F. Maton Sotomayor for taking up this long-lasting thread and reviving the AS112 drafts. I have followed up to both new AS112 drafts, draft-ietf-dnsop-as112-ops-02 and draft-ietf-dnsop-as112-under-attack-help-help-02, and I heartly recommend the WG to now undertake all necessary steps to quickly bring these documents to RFC publication. I do not believe that IPv6 considerations should now hold off these drafts even more. I would diagnose considerable unfairness in the WG against the authors if, after being silent for so many months, this issue would now be raised as a show-stopper. The description in the drafts necessarily is a snapshot in time, and any document on operational considerations could be held off indefinitely by a sustained requirement to add the next generation of considerations. Further, I oppose to attempts to mix in forgery resilience aspects into these documents. These are orthogonal to the topic of these drafts and dealt with in a separate effort. We should not blow up every other document with the never ending discussion on the lazyness of operators in the implementation of efficient RPF in access networks, to raise the hurdles for source address spoofing; doing so would be an effective means to totally stall the WG process. I share the opinion of the authors that the 'fading of comments' after -01 was a clear indication that all interested folks did agree with the drafts, and hence that WG consensus on the drafts should have been declared or finally determined formally. All comments I once had sent in have been acted upon gracefully, and I only found two tiny nits in -help-help-02, which can easily be fixed during RFC Editor processing: - in the first paragraph of the Abstract, common spelling prcatice in RFC prose suggests to s/RFC1918/RFC 1918/ ; - in the last paragraph of Section 1, s/to be be/to be/ . Thus, I'd like to ask the chairs to now quickly proceed with both documents. The updates to -02 have been clerical, and hence, if in your opinion WGLC has been carried out last year, go ahead; otherwise, please issue a short WGLC. Since draft-ietf-dnsop-default-local-zones is an essential complementary document, I repeat my request to go ahead with that draft as well. I heartfully await an immediate one-week WGLC on all three drafts so that the outcome can be discussed at IETF, if necessary. The WG charter has milestones for forwarding to the IESG of all these documents by September 2007 (!). The WG would gradually loose its credibility if it proves continued inability to show progress on chartered work items. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ From ajs@shinkuro.com Thu Mar 12 07:24:14 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D857A3A6B08 for ; Thu, 12 Mar 2009 07:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, MANGLED_TEXT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2wV2K32wyv2 for ; Thu, 12 Mar 2009 07:24:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 417283A6AC7 for ; Thu, 12 Mar 2009 07:24:12 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 63EB12FEA4F4 for ; Thu, 12 Mar 2009 14:24:48 +0000 (UTC) Date: Thu, 12 Mar 2009 10:24:45 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090312142445.GP18975@shinkuro.com> References: <20090304010001.D285A3A68CF@core3.amsl.com> <49B7F130.2040202@nic-naa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B7F130.2040202@nic-naa.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:24:14 -0000 On Wed, Mar 11, 2009 at 01:13:20PM -0400, Eric Brunner-Williams wrote: > Next, it is a convention, which Donald, Bill, and I observed in 2929, > that "[t]ext labels can, in fact, include any octet value including zero > octets but most current uses involve only [US-ASCII]." The nuances I > recall that Donald and I exchanged notes over during the drafting was > that labels could indeed be one octet, or more, and could be any value, > though the practice at the time was the printable range of 7-bit ASCII, > and the LDH subset of that range. So the statement in your section 2 > would be that you'd like to assert a policy for a registry, the IANA > root as it happens, and there's nothing wrong with writing registry > policy, its something of a cottage industry in the ICANN g- and > cc-playpens, but it isn't a protocol specification. It isn't clear to me from the rest of your note: are you collapsing "text" and "alphabetic" in your remarks there? At the risk of becoming a broken record (or, to pick a more recently obsolescent technology, a scratched CD), the precise problem we have to deal with is the "alphabetic restriction" in RFC 1123. Some people think it normative, and others do not. That's an ambiguity even if you personally happen to think the text is clear. Therefore, we need to fix it. Even if you think it is policy (as I do), it may still underpin other protocol issues and therefore properly be the subject of protocol. I made a similar argument on list in more detail yesterday. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From cet1@hermes.cam.ac.uk Thu Mar 12 10:28:23 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D1B3A6B43 for ; Thu, 12 Mar 2009 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=1.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8ynyn7xmeFn for ; Thu, 12 Mar 2009 10:28:22 -0700 (PDT) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 20B7F3A6831 for ; Thu, 12 Mar 2009 10:28:22 -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]:56637) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:cet1) id 1LhoiG-0001FK-59 (Exim 4.70) (return-path ); Thu, 12 Mar 2009 17:28:56 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1LhoiG-0001En-Im (Exim 4.67) (return-path ); Thu, 12 Mar 2009 17:28:56 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 12 Mar 2009 17:28:56 +0000 Date: 12 Mar 2009 17:28:56 +0000 From: Chris Thompson To: wmaton@ryouko.imsb.nrc.ca Message-ID: In-Reply-To: References: X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsop@ietf.org Subject: Re: [DNSOP] Updates to AS 112 WG drafts X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:28:23 -0000 Nit in draft-ietf-dnsop-as112-ops-02 - Section 2.2: The zones listed in Section 2.1 are delegated to the two nameservers BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG (192.175.48.6). Second address should be 192.175.48.42. No big deal except that the current text raises eyebrows: "what, they have the *same* IP address?". Other occurrences of the IP addresses seem to be OK. -- Chris Thompson Email: cet1@cam.ac.uk From cet1@hermes.cam.ac.uk Thu Mar 12 12:22:54 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FCF3A6B73 for ; Thu, 12 Mar 2009 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucxah+u4vS0C for ; Thu, 12 Mar 2009 12:22:53 -0700 (PDT) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by core3.amsl.com (Postfix) with ESMTP id 45C943A6BA4 for ; Thu, 12 Mar 2009 12:22:53 -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]:38796) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:cet1) id 1LhqV8-00039C-GN (Exim 4.70) (return-path ); Thu, 12 Mar 2009 19:23:30 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1LhqV8-0007d7-1y (Exim 4.67) (return-path ); Thu, 12 Mar 2009 19:23:30 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 12 Mar 2009 19:23:29 +0000 Date: 12 Mar 2009 19:23:29 +0000 From: Chris Thompson To: wmaton@ryouko.imsb.nrc.ca Message-ID: In-Reply-To: References: X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsop@ietf.org Subject: Re: [DNSOP] Updates to AS 112 WG drafts X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 19:22:54 -0000 Another (sorry!) nit in draft-ietf-dnsop-as112-ops-02: There are inconsistencies in which of these two URLs is the preferred one to be put in the informational TXT records: http://as112.net/ http://www.as112.net/ In fact, as the DNS is at the moment, the first works only by virtue of browser guesswork (there is no address record for as112.net). Not that I can get any response out of www.as112.net = 204.152.184.180 at the moment, either ... :-( -- Chris Thompson Email: cet1@cam.ac.uk From dhc2@dcrocker.net Fri Mar 13 14:35:41 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45983A694F for ; Fri, 13 Mar 2009 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkhZLS6EKVDy for ; Fri, 13 Mar 2009 14:35:40 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 5252A3A695A for ; Fri, 13 Mar 2009 14:35:40 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-127-59-100.dsl.pltn13.pacbell.net [67.127.59.100]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n2DLaCga031688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Mar 2009 14:36:17 -0700 Message-ID: <49BAD1CC.8080608@dcrocker.net> Date: Fri, 13 Mar 2009 14:36:12 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: dnsop@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9105/Fri Mar 13 04:58:59 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Mar 2009 14:36:17 -0700 (PDT) Subject: [DNSOP] DNS support for DKIM X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:35:41 -0000 Folks, Hi. I maintain DKIM's web site, which includes: DKIM Software and Services Deployment Reports and am interested in adding entries for relevant DNS services. The page lists software, services and consultants that perform DKIM functions. Recent discussions about the use of DNS for DKIM have made clear that we need the page to provide a more detailed listing of specific DKIM-related DNS functions. So the template for the page now covers: > DNS = Supports DNS administration > > _names: Creation of domain names that include underscores > TXT: Creation of DKIM parameters, under underscore name > NS: Creation, under underscore name > wizard: User interface that facilitates creating DKIM-specific > records. I'm interested in adding entries for /all/ software and services (packages, ISPs, DNS providers, etc.) that can perform the necessary DNS functions needed by DKIM. For those wishing to, please complete the template for an entry, per: and send it to me. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@xelerance.com Fri Mar 13 22:07:33 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659D73A685D for ; Fri, 13 Mar 2009 22:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpSz4qTePGdq for ; Fri, 13 Mar 2009 22:07:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 915BF3A6838 for ; Fri, 13 Mar 2009 22:07:32 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id AD0005DF88; Sat, 14 Mar 2009 01:16:33 -0400 (EDT) Date: Sat, 14 Mar 2009 01:16:33 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <200903112349.n2BNn3QF023996@drugs.dv.isc.org> Message-ID: References: <200903112349.n2BNn3QF023996@drugs.dv.isc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 05:07:33 -0000 On Thu, 12 Mar 2009, Mark Andrews wrote: >> The principle here is that there is no error if "for a DS record >> there is no corresponding DNSKEY" and vice versa. All that is needed >> for validation is one "chain of trust." Accepting dangling >> references is not optimal but provides robustness. > > Ed, I'm aware there are multiple ways to do this. However > publishing DS records only precludes some methods. Publishing > DNSKEY records does not preclude any methods as one can > *ALWAYS* generate a DS from a DNSKEY. The reverse requires > you to look up a key which matches which means it must be > available to be available to be looked up. Which can be a good thing. For instance, adding keys to the DLV, I think it is better to give ISC the DS record. If they cannot get the DNSKEY, neither can the world, and then you don't want the DLV entry to be included. Paul From paul.hoffman@vpnc.org Mon Mar 16 08:33:55 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B0728C0DE for ; Mon, 16 Mar 2009 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh07uab1Bv1J for ; Mon, 16 Mar 2009 08:33:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A4DA228C15E for ; Mon, 16 Mar 2009 08:33:54 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GFYXPx071032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Mar 2009 08:34:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 16 Mar 2009 08:34:32 -0700 To: dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 15:33:55 -0000 It feels like a lot of DNSSEC questions these days are being answered by "that's covered if you use RFC 5011". If so, then maybe proper use of RFC 5011 (such as when to assume that a zone is *really* being signed, not just for practice) should be part of draft-ietf-dnsop-rfc4641bis. --Paul Hoffman, Director --VPN Consortium From pk@DENIC.DE Wed Mar 18 09:30:56 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED0D3A6806 for ; Wed, 18 Mar 2009 09:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgiuIjZ1y-rA for ; Wed, 18 Mar 2009 09:30:56 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 337513A6941 for ; Wed, 18 Mar 2009 09:30:56 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.73]) by office.denic.de with esmtp id 1Ljyg1-0007z5-3B; Wed, 18 Mar 2009 17:31:33 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id F0B74158F4F; Wed, 18 Mar 2009 17:31:32 +0100 (CET) Date: Wed, 18 Mar 2009 17:31:32 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20090318163132.GA8085@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:30:57 -0000 Dear WG, this is to initiate a working group last call on "Requirements for Management of Name Servers for the DNS" draft-ietf-dnsop-name-server-management-reqs-02.txt ending Friday, 2009-04-10, 23:59 UTC. The tools site gives easy access to diffs and such under . The document is aimed at a status of "Informational". Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. There will be a five reviewer threshold. Not taking silence as consent, the chairs would like to encourage feedback from non-members of the former "dcoma" design team. -Peter [for the wg chairs] From tglassey@earthlink.net Wed Mar 18 09:36:40 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D973A6A10 for ; Wed, 18 Mar 2009 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUYC7GXRb3wn for ; Wed, 18 Mar 2009 09:36:39 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 59EA43A67E9 for ; Wed, 18 Mar 2009 09:36:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BK+qffxi9jkgOcZy7RsPhR/dXlz2W5aaxhWelBbKdcauOFOe6bTly4o+CEXS9wma; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ljylf-00071Z-DV; Wed, 18 Mar 2009 12:37:23 -0400 Message-ID: <49C12342.9070006@earthlink.net> Date: Wed, 18 Mar 2009 09:37:22 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Peter Koch References: <20090318163132.GA8085@unknown.office.denic.de> In-Reply-To: <20090318163132.GA8085@unknown.office.denic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7947ae98a3d2938cd11c8ae672de8bff18350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:36:40 -0000 Peter Koch wrote: > Dear WG, > > this is to initiate a working group last call on > > "Requirements for Management of Name Servers for the DNS" > draft-ietf-dnsop-name-server-management-reqs-02.txt > Peter - I notice that the standards don't say anything about the EU's Data Integrity Directive which in fact will effect the operations of all public content systems including the DNS servers which are operated in the EU. Why was this never designed into the spec is interesting since the specification may "by law not be used in about 1/3 of the populated world now" without that consideration being in place. Todd Glassey > ending Friday, 2009-04-10, 23:59 UTC. The tools site gives easy access to > diffs and such under > . > > The document is aimed at a status of "Informational". > > Please review the draft and send comments and/or statements of support or > non-support to the WG mailing list. > There will be a five reviewer threshold. Not taking silence as consent, > the chairs would like to encourage feedback from non-members of the former > "dcoma" design team. > > -Peter [for the wg chairs] > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From Ray.Bellis@nominet.org.uk Wed Mar 18 09:52:48 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8D63A6AB7 for ; Wed, 18 Mar 2009 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=0.943, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsX0dutcpLyJ for ; Wed, 18 Mar 2009 09:52:47 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 4781E3A6AA7 for ; Wed, 18 Mar 2009 09:52:46 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Nm6k3xYUPD9yIA9zOfCS+1WuDSapVCST0/c//CixEO29nN7610mgimui NgfO7dYRFo3q9JeNCQqX2guFOWI2NqKPncCNL9UEM/F0Xoaq+IHrDcYaI Pzo2R/SB3/Aat7v; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1237395212; x=1268931212; 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:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[DNSO P]=20WGLC:=20Requirements=20for=20Management=20of=20Name =20Servers=20for=20the=09DNS|Date:=20Wed,=2018=20Mar=2020 09=2016:53:28=20+0000|Message-ID:=20|To: =20TSG=20|Cc:=20IETF=20DNSOP=20WG =20|MIME-Version:=201.0|In-Reply-To:=20<4 9C12342.9070006@earthlink.net>|References:=20<20090318163 132.GA8085@unknown.office.denic.de>=20<49C12342.9070006@e arthlink.net>; bh=oZv548PCU+mZlXyZfzQ9YQfuX7dgIN0DvP69NxUoqOA=; b=anIhxaKSiMN8KEeRMetV9O9eJPSdzwACySsPIr9ezk4yTW//vLsqhBIf TlNR6nXoEnwgo4sLBrhWvvNkLaTHZfbPWTuvZpAPkZ0uJ63/q4TW58ZP2 ohWi+RfKF2pys4g; X-IronPort-AV: E=Sophos;i="4.38,385,1233532800"; d="scan'208";a="9067668" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Mar 2009 16:53:30 +0000 In-Reply-To: <49C12342.9070006@earthlink.net> References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> To: TSG MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 18 Mar 2009 16:53:28 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/03/2009 04:53:30 PM, Serialize complete at 18/03/2009 04:53:30 PM Content-Type: multipart/alternative; boundary="=_alternative 005CC9238025757D_=" Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:52:48 -0000 This is a multipart message in MIME format. --=_alternative 005CC9238025757D_= Content-Type: text/plain; charset="US-ASCII" > Peter - I notice that the standards don't say anything about the EU's > Data Integrity Directive which in fact will effect the operations of all > public content systems including the DNS servers which are operated in > the EU. Why was this never designed into the spec is interesting since > the specification may "by law not be used in about 1/3 of the populated > world now" without that consideration being in place. Todd, A Google search for the term "Data Integrity Directive" returns only one (irrelevant) result. Could you perhaps let us know which EU Directive you really meant? regards Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 005CC9238025757D_= Content-Type: text/html; charset="US-ASCII"
> Peter - I notice that the standards don't say anything about the EU's
> Data Integrity Directive which in fact will effect the operations of all
> public content systems including the DNS servers which are operated in
> the EU. Why was this never designed into the spec is interesting since
> the specification may "by law not be used in about 1/3 of the populated
> world now" without that consideration being in place.
Todd,

A Google search for the term "Data Integrity Directive" returns only one (irrelevant) result.

Could you perhaps let us know which EU Directive you really meant?

regards

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 005CC9238025757D_=-- From paul.hoffman@vpnc.org Wed Mar 18 10:12:03 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3367328C15F for ; Wed, 18 Mar 2009 10:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqP5f4gNQG+r for ; Wed, 18 Mar 2009 10:12:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2D41028C1C7 for ; Wed, 18 Mar 2009 10:12:01 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2IHChws059712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Mar 2009 10:12:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090318163132.GA8085@unknown.office.denic.de> References: <20090318163132.GA8085@unknown.office.denic.de> Date: Wed, 18 Mar 2009 10:12:42 -0700 To: IETF DNSOP WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:12:03 -0000 >Please review the draft and send comments and/or statements of support or >non-support to the WG mailing list. I have just re-read the draft and support its publication. Wearing my security-weenie hat, I find that section 4 is an excellent, concise set of security requirements. --Paul Hoffman, Director --VPN Consortium From jabley@hopcount.ca Wed Mar 18 10:17:09 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11263A6AD4 for ; Wed, 18 Mar 2009 10:17:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSAs1twTfqkS for ; Wed, 18 Mar 2009 10:17:08 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 248AA3A681F for ; Wed, 18 Mar 2009 10:17:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=bBUi/u1KocBKNSGCx9N2k4aurqYP0/YafI+NGMeNg21cLbvG7PbNKDFGJ3sCLImXZ5G3cfpdJp5VvNb8BXJgWc4ZJOMa+Weeoxta3T6DtFiDghAg0bxc3g4rGkeO96vE; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LjzOm-000LUf-BS; Wed, 18 Mar 2009 17:17:48 +0000 Message-Id: From: Joe Abley To: TSG In-Reply-To: <49C12342.9070006@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 13:17:48 -0400 References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> X-Mailer: Apple Mail (2.930.3) Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:17:09 -0000 On 18 Mar 2009, at 12:37, TSG wrote: > Peter - I notice that the standards don't say anything about the > EU's Data Integrity Directive I can't comment on that directive in particular (if indeed such a directive with that name exists, per later mail) but in general I find it a feature that a document with operational focus addressed to the whole Internet should steer clear of regional policy requirements. Joe From tglassey@earthlink.net Wed Mar 18 10:27:36 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856D53A681F for ; Wed, 18 Mar 2009 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga5dRYfUpC8p for ; Wed, 18 Mar 2009 10:27:35 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 11AF228C1C7 for ; Wed, 18 Mar 2009 10:27:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=J82bk2saHKXVe/UZovpu1ksEjaY3/iua23wM1lg99dv6Gl1K3i/O+vTArA1WhpbK; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LjzYx-0007IH-6c; Wed, 18 Mar 2009 13:28:19 -0400 Message-ID: <49C12F31.4000106@earthlink.net> Date: Wed, 18 Mar 2009 10:28:17 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7988bed1c71abceb83bade0e6547200f3f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:27:36 -0000 Ray.Bellis@nominet.org.uk wrote: > > > Peter - I notice that the standards don't say anything about the EU's > > Data Integrity Directive which in fact will effect the operations of > all > > public content systems including the DNS servers which are operated in > > the EU. Why was this never designed into the spec is interesting since > > the specification may "by law not be used in about 1/3 of the populated > > world now" without that consideration being in place. > > Todd, > > A Google search for the term "Data Integrity Directive" returns only > one (irrelevant) result. > > Could you perhaps let us know which EU Directive you really meant? Uh, sorry - here are a few of the many links provided. The EU has all sorts of new Directives on Data Integrity and the IETF can thank the RFC3161 team for some of this. o- http://www.google.com/search?q=eu+data+protection+directive&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a o- http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm o- http://www.cdt.org/privacy/eudirective/EU_Directive_.html Those same standards directly apply to anything using time to invalidate the use of a policy control - as in a time, DNS, NEA, or most other time-policy controlled servers - and that is for ANY digital control purpose. That same requirement (to prove the actual functionality in a world-class test environment that meets the needs of the EU) actually prevents RFC3161 or any other IETF standard which wasn't tested under those standards from being deployed since the law now pertains to all systems in place and has no grandfathering provision to address legacy systems designed and implemented before those requirements were put into place. As to who is responsible, the WG Chairs and the project Sponsors and IMHO you can also thank the IETF's legal service for this failure since it is their direct responsibility to advise the IETF on these key issues of International Law. The real issue *** AGAIN *** is whether IETF standards were tested in environment's which stress the protocol or technology based on these operating requirements. In all instances to date the answer is no meaning that unless the EU creates a specific exemption for the IETF's standards it by its own laws MAY NOT RELY ON IETF WORK PRODUCT for anything... Todd Glassey > > regards > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > ------------------------------------------------------------------------ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From wmaton@ryouko.imsb.nrc.ca Wed Mar 18 10:32:53 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F4F3A6982 for ; Wed, 18 Mar 2009 10:32:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rkXeDHWIK-5 for ; Wed, 18 Mar 2009 10:32:52 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2001:410:9000:127::10]) by core3.amsl.com (Postfix) with ESMTP id 1FEC63A6826 for ; Wed, 18 Mar 2009 10:32:52 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.3) with ESMTP id n2IHXM8g026944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2009 13:33:27 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.3/8.14.3/Submit) with ESMTP id n2IHXL8a026941; Wed, 18 Mar 2009 13:33:21 -0400 Date: Wed, 18 Mar 2009 13:33:21 -0400 (EDT) From: "William F. Maton Sotomayor" To: Joe Abley In-Reply-To: Message-ID: References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Koch , TSG , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:32:53 -0000 Yeah, I agree with Joe here. If one local initiative starts meandering in, then all of them would follow in too. On Wed, 18 Mar 2009, Joe Abley wrote: > > On 18 Mar 2009, at 12:37, TSG wrote: > >> Peter - I notice that the standards don't say anything about the EU's Data >> Integrity Directive > > I can't comment on that directive in particular (if indeed such a directive > with that name exists, per later mail) but in general I find it a feature > that a document with operational focus addressed to the whole Internet should > steer clear of regional policy requirements. > > > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop wfms From tglassey@earthlink.net Wed Mar 18 10:36:11 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F3C3A6AD4 for ; Wed, 18 Mar 2009 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+0tdBtFvb8F for ; Wed, 18 Mar 2009 10:36:10 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 3CDCB3A69BD for ; Wed, 18 Mar 2009 10:36:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A73YKGVcoDUUamm3uHhRMMof+O4OdW5ivoe9CVM8vsv35umM4RtUwpKUidEUPLjo; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LjzhD-0001ml-N4; Wed, 18 Mar 2009 13:36:51 -0400 Message-ID: <49C13132.7030402@earthlink.net> Date: Wed, 18 Mar 2009 10:36:50 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joe Abley References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79641b02060e6ad424f3cb571ea807bd68350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:36:11 -0000 Joe Abley wrote: > > On 18 Mar 2009, at 12:37, TSG wrote: > >> Peter - I notice that the standards don't say anything about the EU's >> Data Integrity Directive > > I can't comment on that directive in particular (if indeed such a > directive with that name exists, per later mail) but in general I find > it a feature that a document with operational focus addressed to the > whole Internet should steer clear of regional policy requirements. Then commentary needs to be added to the Boiler Plate that no regional issues were addressed in the testing - hence a test bed based on the requirements for operating a data-center in the EU were not considered. That's OK but it means that many in the EU may not be able to deploy those protocols in their operating environments until those specific implementations are tested now that the audit world is waking up to its responsibilities under the digital evidence requirements globally. If this turns out to be true - it will effect all IETF standards in use today in the EU. Todd Glassey > > > Joe > From tglassey@earthlink.net Wed Mar 18 10:37:48 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93AA28C1D6 for ; Wed, 18 Mar 2009 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxtFQXmUD70T for ; Wed, 18 Mar 2009 10:37:48 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 33C4B28C1D0 for ; Wed, 18 Mar 2009 10:37:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Bj+PTErmPQN8wc0ljHdADP99sxtEeBkN2lbUw0jQdzpGq0IDSIjgNgrY3Hlfg5t/; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ljzin-0004g7-49; Wed, 18 Mar 2009 13:38:29 -0400 Message-ID: <49C13193.5010102@earthlink.net> Date: Wed, 18 Mar 2009 10:38:27 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: wmaton@ryouko.imsb.nrc.ca References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e79b63b5642341b167862535a8c18cf8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG , Peter Koch , Joe Abley Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:37:49 -0000 William F. Maton Sotomayor wrote: > > Yeah, I agree with Joe here. If one local initiative starts > meandering in, then all of them would follow in too. ... (in my best sarcastic tone) So then you are saying that the IETF will exclude the testing of its protocols in real-world use models. Cool - that makes a lot of good sense (yeah right). Todd Glassey > > On Wed, 18 Mar 2009, Joe Abley wrote: > >> >> On 18 Mar 2009, at 12:37, TSG wrote: >> >>> Peter - I notice that the standards don't say anything about the >>> EU's Data Integrity Directive >> >> I can't comment on that directive in particular (if indeed such a >> directive with that name exists, per later mail) but in general I >> find it a feature that a document with operational focus addressed to >> the whole Internet should steer clear of regional policy requirements. >> >> >> Joe >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > wfms > From sthaug@nethelp.no Wed Mar 18 11:39:04 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A575728C1DD for ; Wed, 18 Mar 2009 11:39:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TniToOHtuHp9 for ; Wed, 18 Mar 2009 11:39:04 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by core3.amsl.com (Postfix) with SMTP id 6BAE328C1C0 for ; Wed, 18 Mar 2009 11:39:03 -0700 (PDT) Received: (qmail 60172 invoked from network); 18 Mar 2009 18:39:46 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Mar 2009 18:39:46 -0000 Date: Wed, 18 Mar 2009 19:39:46 +0100 (CET) Message-Id: <20090318.193946.74736737.sthaug@nethelp.no> To: tglassey@earthlink.net From: sthaug@nethelp.no In-Reply-To: <49C13132.7030402@earthlink.net> References: <49C12342.9070006@earthlink.net> <49C13132.7030402@earthlink.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org, pk@DENIC.DE, jabley@hopcount.ca Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 18:39:04 -0000 > > I can't comment on that directive in particular (if indeed such a > > directive with that name exists, per later mail) but in general I find > > it a feature that a document with operational focus addressed to the > > whole Internet should steer clear of regional policy requirements. Agreed. > Then commentary needs to be added to the Boiler Plate that no regional > issues were addressed in the testing - hence a test bed based on the > requirements for operating a data-center in the EU were not considered. I see no way that "Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of *personal data and on the free movement of such data*" (my emphasis) is relevant for this requirements document. > That's OK but it means that many in the EU may not be able to deploy > those protocols in their operating environments until those specific > implementations are tested now that the audit world is waking up to its > responsibilities under the digital evidence requirements globally. I note that this is a directive from 1995. Yes, we have seen effects of this directive, even here in Norway (not a EU member) - but I think you are going way beyond what the EU directive is meant to cover when you say it is relevant for the name server requirements document. My opinins only, IANAL. > If this turns out to be true - it will effect all IETF standards in use > today in the EU. The EU directive deals with explicitly *personal data* and the storage and movement of such data. It does not deal with *all data*. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sm@resistor.net Wed Mar 18 15:30:39 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C92C3A6806 for ; Wed, 18 Mar 2009 15:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSZmBeSMVSp for ; Wed, 18 Mar 2009 15:30:38 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 8B6B23A6359 for ; Wed, 18 Mar 2009 15:30:38 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n2IMVCda011740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Mar 2009 15:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1237415481; x=1237501881; bh=3VsHywVViy1ZhYY1YqexejHNDSjr3UlQswlVeGLfw2A=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dtmheLfgywYcH/k5lJVaRHxU5xxMsmhOh3o/Jok6sMM6tEuv/xq4AU1zVadyvjYoG t8HqsGU+gfS78T/WuLCu06Qaf13B16gjzdkV8EAep8Dd8+MpOEP/zuXUcxr/YfR9xE AG68y/1JyhHOq+DowY7D/181ngvIXbLF9Vb/KxL0= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=wAoICxNQ7ATB0pdV3n21cVHCRSClvJMvopbIIIB0up/roWzV6rEiwOxW7GBIkT9Bi bfshw1O/Xomlg/iJrReK1YfhZ89B9xtEt4l38mUJZ4ehNC5Kc5fzicln9drMYdYneI6 Pd8/Nc3x3q6WbX4hasNe1v2beaKZjNJ5GIvY6Q4= Message-Id: <6.2.5.6.2.20090318145913.0303a900@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Mar 2009 15:30:57 -0700 To: IETF DNSOP WG From: SM In-Reply-To: References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 22:30:39 -0000 At 10:17 18-03-2009, Joe Abley wrote: >I can't comment on that directive in particular (if indeed such a >directive with that name exists, per later mail) but in general I find >it a feature that a document with operational focus addressed to the >whole Internet should steer clear of regional policy requirements. I couldn't find such a directive. The question might have been raised due to some confusion with the directive about data protection. The draft is about the requirements for a management system for DNS name servers instead of country-specific policy requirements. Regards, -sm From tglassey@earthlink.net Wed Mar 18 15:31:31 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1E83A6997 for ; Wed, 18 Mar 2009 15:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUAhw6cIjQda for ; Wed, 18 Mar 2009 15:31:30 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C63D13A688D for ; Wed, 18 Mar 2009 15:31:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Dbml6NQvgp/goNNf8hIHteeA0cg3ze5rFjWg1ICvOaON01KMEQPr8iv8S1zVaN+0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lk4Iz-0003dv-6h; Wed, 18 Mar 2009 18:32:09 -0400 Message-ID: <49C17667.3000008@earthlink.net> Date: Wed, 18 Mar 2009 15:32:07 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: wmaton@ryouko.imsb.nrc.ca References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799866e2ed9cc5c0bec42cbbb082913dbe350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG , Peter Koch , Joe Abley Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 22:31:31 -0000 William F. Maton Sotomayor wrote: > > Yeah, I agree with Joe here. If one local initiative starts > meandering in, then all of them would follow in too. > I forgot to bring up that you are apparently saying that Standards are exempt from the laws of this planet. Is this more of the "pay no attention to the man in the white coat" commentary? Todd > > On Wed, 18 Mar 2009, Joe Abley wrote: > >> >> On 18 Mar 2009, at 12:37, TSG wrote: >> >>> Peter - I notice that the standards don't say anything about the >>> EU's Data Integrity Directive >> >> I can't comment on that directive in particular (if indeed such a >> directive with that name exists, per later mail) but in general I >> find it a feature that a document with operational focus addressed to >> the whole Internet should steer clear of regional policy requirements. >> >> >> Joe >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > wfms > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From tglassey@earthlink.net Wed Mar 18 15:53:08 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F29528C0E5 for ; Wed, 18 Mar 2009 15:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N6HMGwo0U6F for ; Wed, 18 Mar 2009 15:53:07 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id F080A3A6823 for ; Wed, 18 Mar 2009 15:53:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JKlz23Mujpw87YV3baqplt2Lc9DY16Q1ltvdhKm0uNloDnbqaE9G+DWdC5Lih4av; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lk4dz-0008HV-7Y; Wed, 18 Mar 2009 18:53:51 -0400 Message-ID: <49C17B7D.80305@earthlink.net> Date: Wed, 18 Mar 2009 15:53:49 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: SM References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <6.2.5.6.2.20090318145913.0303a900@resistor.net> In-Reply-To: <6.2.5.6.2.20090318145913.0303a900@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793295155a4fccccbe713280220fe624ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 22:53:08 -0000 SM wrote: > At 10:17 18-03-2009, Joe Abley wrote: >> I can't comment on that directive in particular (if indeed such a >> directive with that name exists, per later mail) but in general I find >> it a feature that a document with operational focus addressed to the >> whole Internet should steer clear of regional policy requirements. > > I couldn't find such a directive. The question might have been raised > due to some confusion with the directive about data protection. The > draft is about the requirements for a management system for DNS name > servers instead of country-specific policy requirements. The Data Integrity and Security Models apply to the DNS systems as well. Since these are key to the security models which are used to protect privacy impacted and financial data they are also included. I think this is inherently obvious, in fact its so obvious that arguing about it is silly. The access model for the (seamless information control/access process) at hand is also controlled by the Data Integrity directives too. The idea that the systems which control access to these protected data are not also protected is laughable IMHO Todd > > Regards, > -sm > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From tglassey@earthlink.net Wed Mar 18 17:04:16 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5AA3A68E6 for ; Wed, 18 Mar 2009 17:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVofQw21c4vX for ; Wed, 18 Mar 2009 17:04:15 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 2DA703A6922 for ; Wed, 18 Mar 2009 17:04:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gAJjE+kql7MA5imaIgnDh4FsDCkllOzM4ztdRtTWlddof1TNMKtM6WhexQH+a+p4; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lk5kp-000247-8J; Wed, 18 Mar 2009 20:04:59 -0400 Message-ID: <49C18C29.1010502@earthlink.net> Date: Wed, 18 Mar 2009 17:04:57 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: SM References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <6.2.5.6.2.20090318145913.0303a900@resistor.net> <49C17B7D.80305@earthlink.net> In-Reply-To: <49C17B7D.80305@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f02dc940c9f3db8a76a0cb387cf37c5e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:04:16 -0000 Let's us paint a picture... >> > The Data Integrity and Security Models apply to the DNS systems as > well. Since these are key to the security models which are used to > protect privacy impacted and financial data they are also included. I > think this is inherently obvious, in fact its so obvious that arguing > about it is silly. The access model for the (seamless information > control/access process) at hand is also controlled by the Data > Integrity directives too. The idea that the systems which control > access to these protected data are not also protected is laughable IMHO > > Todd >> So a Medical Records Purveyor in the UK puts their data online for Doctor's to download. And because of the BGP4 Routing Flap the MitM Attack is seamlessly functional. After some period of time the DNS records in the master Root Server are compromised and the pointer to the Records Bureau is changed to point to a server being operated off of a boat in the Indian Ocean. This one is specific to a particular person's medical history, and so then you as the competent member of the Treadway project simply contaminate the person's food with some shellfish extract and poof - Anaphylaxis and the target is kaput. This is a specific hack where DNS would be used effectively to kill someone by redirecting the Medical Records Bureau where this patients data resides to a new faked system, and as long as it worked like it was supposed to which wouldn't be to hard to fake, the relying Doctor would never know. Now - once again - the integrity of the DNS being requested for ANY act which would provide data to a user wherein that data is controlled by a Privacy Act or likewise the EU Data Integrity Act, would also constrain here as well. The funniest part is that I bet that the RFC3161 crowd still doesnt get that the EU Timestamping Directives apply directly to the management of systems logs in the EU as well. - Cracks me up! Todd Glassey >> Regards, >> -sm >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From jabley@hopcount.ca Wed Mar 18 17:52:54 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24743A6ABC for ; Wed, 18 Mar 2009 17:52:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC+TX-IlA-hj for ; Wed, 18 Mar 2009 17:52:54 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id E2C513A68D2 for ; Wed, 18 Mar 2009 17:52:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=azc252lGIXZuK2HRElxddTiDnIVy4fQwVQe2DgVnoh+Yh9/T8D054DBVTNVxjBFJ0wN00dR56B0QO7tYy+g6OlVGrWuJxhzaZkg+8jFyPdA2tjvBoWxICKa8+1RQhZ6+; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lk6Vp-000Puc-2c; Thu, 19 Mar 2009 00:53:33 +0000 Message-Id: <3E33575D-0946-4675-BD35-07A3924D11A0@hopcount.ca> From: Joe Abley To: TSG In-Reply-To: <49C17667.3000008@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 20:53:32 -0400 References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <49C17667.3000008@earthlink.net> X-Mailer: Apple Mail (2.930.3) Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:52:55 -0000 On 18 Mar 2009, at 18:32, TSG wrote: > I forgot to bring up that You're hilarious, Todd :-) Joe From tglassey@earthlink.net Wed Mar 18 18:32:22 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC473A6B08 for ; Wed, 18 Mar 2009 18:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxEFGLeAmF7P for ; Wed, 18 Mar 2009 18:32:21 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id AAB043A6866 for ; Wed, 18 Mar 2009 18:32:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LZS+IgcTWiAie/pF6OmyGu4pNc2v5gQbQ2vRXD6lXgHU56mGIuS0nl1Ov6bfTu4k; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lk784-0000gD-Fs; Wed, 18 Mar 2009 21:33:04 -0400 Message-ID: <49C1A0CE.4090705@earthlink.net> Date: Wed, 18 Mar 2009 18:33:02 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joe Abley References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <49C17667.3000008@earthlink.net> <3E33575D-0946-4675-BD35-07A3924D11A0@hopcount.ca> In-Reply-To: <3E33575D-0946-4675-BD35-07A3924D11A0@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f5b749310755f27d6fa3ca16d908ac14350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 01:32:22 -0000 Joe Abley wrote: > > On 18 Mar 2009, at 18:32, TSG wrote: > >> I forgot to bring up that > > You're hilarious, Todd :-) You think??? - I thought it was the other way around but actually what's funny is that Article 6 of the act talks to "Data Processing" which is a phrase which pertains to "the System which performs the Data Manipulations" not just the protected PII-constrained portable-data belonging to the parties ... Wanna bet on it? Here is the link. http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_2 - the same is true that the time-service is also impacted by the EU directive there but that also rolls down to the same service which EU residents and member's must bring into that operations. Nice move that one too... Todd Glassey > > > Joe > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From sm@resistor.net Wed Mar 18 20:48:08 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471EC3A6B35 for ; Wed, 18 Mar 2009 20:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAap2D70gdrM for ; Wed, 18 Mar 2009 20:48:07 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 56C0C28C163 for ; Wed, 18 Mar 2009 20:48:07 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n2J3mggu026921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Mar 2009 20:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1237434530; x=1237520930; bh=fW9v16w4H7BlihFAVMDV6Zyu1Nqja64bIdvKymNdujI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=KaWgk1vDcT9FWjed/VYFdUecK/KOALrVSm+lx0N065h+MNqz9uSP7rWU5wkm12768 IbmLvmLWEq+JHwF3iPzl70BR6pVmzgFdnZOluH38kIYHLfmsWXgedubrSTTfkKktbk stuuV3cXC7MBhPUrHqsDWvQvZJWHkIav1SgiCekI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=SMW+x41cAkF5x+xFGIKGWdJaq7n12Wdz0vrpoqju43I+kueALWbEXqkQ64PXD/g0k LY9nrepgj4O3oHtKInl88zwyYTteu1d498z2qTxyyiiRAp7gz6TMWyV8RTMqSqOjI2H 8RpVfIskKD0t5hSX7Z73zPiMp0vu5PrdVkgeB6E= Message-Id: <6.2.5.6.2.20090318195712.02fe5468@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Mar 2009 20:45:57 -0700 To: IETF DNSOP WG From: SM In-Reply-To: <49C17B7D.80305@earthlink.net> References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <6.2.5.6.2.20090318145913.0303a900@resistor.net> <49C17B7D.80305@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 03:48:08 -0000 At 15:53 18-03-2009, TSG wrote: >The Data Integrity and Security Models apply to the DNS systems as >well. Since these are key to the security models which are used to >protect privacy impacted and financial data they are also included. I think >this is inherently obvious, in fact its so obvious that arguing >about it is silly. The You mentioned the "EU's Data Integrity Directive" to back an argument about protecting privacy. As you have not provided any reference to such a directive, I'll assume that it does not exist. At 17:04 18-03-2009, TSG wrote: >Let's us paint a picture... [snip] >Now - once again - the integrity of the DNS being requested for ANY >act which would provide data to a user wherein that data is >controlled by a Privacy Act or likewise the EU Data Integrity Act, >would also constrain here as well. The funniest part is that I bet >that the RFC3161 crowd still doesnt get that the EU Timestamping >Directives apply directly to the management of systems logs in the >EU as well. - Cracks me up! There isn't any "EU Data Integrity Act". Securing information through DNS won't get you far. At 18:33 18-03-2009, TSG wrote: >Here is the link. >http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_2 - the You could at least use a source of information from the European Union if you are going to paint pictures about Europe. Regards, -sm From olaf@NLnetLabs.nl Thu Mar 19 01:40:55 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753983A6B83 for ; Thu, 19 Mar 2009 01:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh83LB6NfisQ for ; Thu, 19 Mar 2009 01:40:54 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 14CCD3A6AF8 for ; Thu, 19 Mar 2009 01:40:53 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:21b:63ff:fe94:3816] ([IPv6:2001:7b8:206:1:21b:63ff:fe94:3816]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n2J8fZm8047872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Mar 2009 09:41:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Message-Id: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> From: Olaf Kolkman To: Paul Hoffman In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-54--700626280" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 09:41:34 +0100 References: X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 19 Mar 2009 09:41:35 +0100 (CET) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 08:40:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-54--700626280 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 16 mrt 2009, at 16:34, Paul Hoffman wrote: > It feels like a lot of DNSSEC questions these days are being > answered by "that's covered if you use RFC 5011". If so, then maybe > proper use of RFC 5011 (such as when to assume that a zone is > *really* being signed, not just for practice) should be part of > draft-ietf-dnsop-rfc4641bis. I think you have a point. I can imagine that such section would be about putting trust in a trust-anchor and the considerations that apply there. Shooting from the hip here are some considerations: - When to trust a trust anchor: * whenever the zone-owner declares that a key is ready to be used as trust-anchor and * whenever you, as validator administrator, are satisfied that the rollover procedure is documented clearly enough and you are confident you can track the rollovers - When not to trust a trust anchor: * when a key appears in a zone and there is no trusted out-of-band communication that such key is in production. - Cases where transitive trust may work: * when a trusted third party validates the key-zone binding, the production readiness, and tracks the keys. (ITAR) * when copying zone data from a parental zone to which you have a DNS trust relation. I can see rare cases why you would want to establish a trust- anchor in the middle of a chain of trust that is in place. But if you follow this route I'm not sure about if there is a fate sharing argument that renders this sort of configuration useless. Obvious missing points? I've added this as open issue: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration --Olaf --Apple-Mail-54--700626280 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAknCBT8ACgkQtN/ca3YJIofBOQCfYVqMVPtuNdGQEAaku5DN66aB tfkAoIV45SViKfdUXvdnKW19x4fjgXTJ =p3aV -----END PGP SIGNATURE----- --Apple-Mail-54--700626280-- From denic@eng.colt.net Thu Mar 19 03:03:17 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0463A6843 for ; Thu, 19 Mar 2009 03:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAyO0WgXLJWj for ; Thu, 19 Mar 2009 03:03:16 -0700 (PDT) Received: from smtp.lon.dcn.colt.net (smtp.lon.server.COLT.NET [212.74.77.49]) by core3.amsl.com (Postfix) with ESMTP id 536AA3A67D7 for ; Thu, 19 Mar 2009 03:03:15 -0700 (PDT) Received: from [192.168.42.101] (unknown [212.74.90.79]) by smtp.lon.dcn.colt.net (Postfix) with ESMTP id 8947435835; Thu, 19 Mar 2009 11:03:59 +0100 (CET) From: Ralf Weber To: TSG In-Reply-To: <49C12342.9070006@earthlink.net> References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> Message-Id: <5F2A5E71-1ADB-4831-903B-847610ACC7A1@eng.colt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 11:03:58 +0100 X-Mailer: Apple Mail (2.930.3) Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 10:03:17 -0000 Moin! On 18.03.2009, at 17:37, TSG wrote: > Peter Koch wrote: >> Dear WG, >> >> this is to initiate a working group last call on >> >> "Requirements for Management of Name Servers for the DNS" >> draft-ietf-dnsop-name-server-management-reqs-02.txt >> > Peter - I notice that the standards don't say anything about the =20 > EU's Data Integrity Directive which in fact will effect the =20 > operations of all public content systems including the DNS servers =20 > which are operated in the EU. Why was this never designed into the =20 > spec is interesting since the specification may "by law not be used =20= > in about 1/3 of the populated world now" without that consideration =20= > being in place. I'm not sure where you get the numbers, but the EU's population is =20 around 499 million, the worlds population is 6700 million, to me that =20= makes roughly 8%. Also every EU directive has to be set into law by =20 the member states, and in that case at least in the federal system of =20= germany and austria this had to be done by the states. So the rough =20 count I had this directive has been passed into 46 different laws, of =20= course in different languages. Are you going to check them all? Of course operators in the respective legislations are required to =20 obey to the law, and working for an pan european ISP I can tell you =20 that this is not easy sometimes, because law differs from country to =20 country, but we still provide services based on the standards set bey =20= the IETF. These have to be technically sound but IMHO it is not the =20 task of this working group to see if they, or to be more precise =20 implementation of these standards may impose legal risks in certain =20 countries. I know the implementation of this directive in germany (Bundes/=20 Landesdatenschutzgesetz for the germans around here) and I can not see =20= how it would apply to this draft, then of course IANAL. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Sch=FCtze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra=DFe 4, 60528 Frankfurt/Main, Deutschland =20= * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch=E4ftsf=FChrer: Dr. J=FCrgen Hernichel (Vors.), Rita Thies * =20 Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From jim@rfc1035.com Thu Mar 19 03:10:40 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A7D28C1FA for ; Thu, 19 Mar 2009 03:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbHQoZszxXB4 for ; Thu, 19 Mar 2009 03:10:40 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 8B0593A67DF for ; Thu, 19 Mar 2009 03:10:39 -0700 (PDT) Received: from [217.33.138.50] (account jim HELO [172.16.1.47]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 410682 for dnsop@ietf.org; Thu, 19 Mar 2009 10:11:23 +0000 Message-Id: From: Jim Reid To: IETF DNSOP WG In-Reply-To: <49C1A0CE.4090705@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 10:10:21 +0000 References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <49C17667.3000008@earthlink.net> <3E33575D-0946-4675-BD35-07A3924D11A0@hopcount.ca> <49C1A0CE.4090705@earthlink.net> X-Mailer: Apple Mail (2.930.3) Subject: [DNSOP] EU Data Protection Directives and draft-ietf-dnsop-name-server-management-reqs- X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 10:10:40 -0000 Can we *please* get back to a discussion of WGLC on this ID? The (largely ill-informed) debate about EU Data Protection Directives can be taken somewhere else. It's not even remotely relevant to this WG or the draft that's under consideration. From peter@denic.de Thu Mar 19 03:46:46 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4913A6969 for ; Thu, 19 Mar 2009 03:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24PPehMBMt9A for ; Thu, 19 Mar 2009 03:46:45 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 3A6C33A6931 for ; Thu, 19 Mar 2009 03:46:44 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LkFma-0003KT-Hi; Thu, 19 Mar 2009 11:47:28 +0100 Received: from localhost by x27.adm.denic.de with local id 1LkFjb-0007wt-CT; Thu, 19 Mar 2009 11:44:23 +0100 Date: Thu, 19 Mar 2009 11:44:23 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20090319104423.GF27049@x27.adm.denic.de> References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <5F2A5E71-1ADB-4831-903B-847610ACC7A1@eng.colt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5F2A5E71-1ADB-4831-903B-847610ACC7A1@eng.colt.net> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] /adm/ Re: WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 10:46:46 -0000 On 18.03.2009, at 17:37, TSG wrote: > >Peter - I notice that the standards don't say anything about the > >EU's Data Integrity Directive which in fact will effect the On Thu, Mar 19, 2009 at 11:03:58AM +0100, Ralf Weber wrote: > I'm not sure where you get the numbers, but the EU's population is > around 499 million, the worlds population is 6700 million, to me that [... others omitted ...] Folks, please. We're trying to discuss and potential issues with it. Absent any evidence of its relevance, I consider the sub-thread on the EU Directive on data protection closed. -Peter [co-chair hat on] From tglassey@earthlink.net Thu Mar 19 06:45:47 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311D03A6BDA for ; Thu, 19 Mar 2009 06:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lHsngE9tE7p for ; Thu, 19 Mar 2009 06:45:46 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id F0A6628C14A for ; Thu, 19 Mar 2009 06:45:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ReDOINNVQksikiV5m/kI4W5l43s9aXGZkbHbpLmSBgSIckfNeu+G1/ugsdlMl1tf; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LkIZo-00006A-Dv; Thu, 19 Mar 2009 09:46:28 -0400 Message-ID: <49C24CB2.4010301@earthlink.net> Date: Thu, 19 Mar 2009 06:46:26 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ralf Weber References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <5F2A5E71-1ADB-4831-903B-847610ACC7A1@eng.colt.net> In-Reply-To: <5F2A5E71-1ADB-4831-903B-847610ACC7A1@eng.colt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796cab2f3513b956c0e61b348233a528b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 13:45:47 -0000 Ralf Weber wrote: > Moin! > > On 18.03.2009, at 17:37, TSG wrote: > >> Peter Koch wrote: >>> Dear WG, >>> >>> this is to initiate a working group last call on >>> >>> "Requirements for Management of Name Servers for the DNS" >>> draft-ietf-dnsop-name-server-management-reqs-02.txt >>> >> Peter - I notice that the standards don't say anything about the EU's >> Data Integrity Directive which in fact will effect the operations of >> all public content systems including the DNS servers which are >> operated in the EU. Why was this never designed into the spec is >> interesting since the specification may "by law not be used in about >> 1/3 of the populated world now" without that consideration being in >> place. > I'm not sure where you get the numbers, but the EU's population is > around 499 million, the worlds population is 6700 million, to me that > makes roughly 8%. Also every EU directive has to be set into law by > the member states, and in that case at least in the federal system of > germany and austria this had to be done by the states. So the rough > count I had this directive has been passed into 46 different laws, of > course in different languages. Are you going to check them all? > > Of course operators in the respective legislations are required to > obey to the law, and working for an pan european ISP I can tell you > that this is not easy sometimes, because law differs from country to > country, but we still provide services based on the standards set bey > the IETF. These have to be technically sound but IMHO it is not the > task of this working group to see if they, or to be more precise > implementation of these standards may impose legal risks in certain > countries. > > I know the implementation of this directive in germany > (Bundes/Landesdatenschutzgesetz for the germans around here) and I can > not see how it would apply to this draft, then of course IANAL. Ralf - where I got that number is based on the populated areas of the planet. That said, the EU based on Europe and Canada & Australia (including India's population + the EU) falls somewhere roughly from 1/3 to 1/2 of the global population > > So long > -Ralf > --- > Ralf Weber > Platform Infrastructure Manager > Colt Telecom GmbH > Herriotstrasse 4 > 60528 Frankfurt > Germany > DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 > Fax: +49 (0)69 56606 6280 > Email: rw@colt.net > http://www.colt.net/ > Data | Voice | Managed Services > > Schütze Deine Umwelt | Erst denken, dann drucken > > ***************************************** > COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland > * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * > > Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * > Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 > > > > > > From matthijs@nlnetlabs.nl Thu Mar 19 10:48:13 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AC03A6A2B for ; Thu, 19 Mar 2009 10:48: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWu5UCKkWUVE for ; Thu, 19 Mar 2009 10:48:12 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id EA8583A6814 for ; Thu, 19 Mar 2009 10:48:11 -0700 (PDT) Received: from [192.168.1.12] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n2JHmouB039797; Thu, 19 Mar 2009 18:48:51 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <49C28582.8030605@nlnetlabs.nl> Date: Thu, 19 Mar 2009 18:48:50 +0100 From: Matthijs Mekking Organization: Stichting NLnet Labs User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Olaf Kolkman References: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> In-Reply-To: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [213.154.224.1]); Thu, 19 Mar 2009 18:48:51 +0100 (CET) Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 17:48:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also, RFC 5011 may adapt key rollover practices. In short this means that when a key may be removed because it is considered dead, it should stay in the zone for one RRSIG TTL more with its REVOKED bit set before removing it from the zone. This way, rfc5011 enabled resolvers can update their trust anchors in-band. Matthijs Olaf Kolkman schreef: > > On 16 mrt 2009, at 16:34, Paul Hoffman wrote: > >> It feels like a lot of DNSSEC questions these days are being answered >> by "that's covered if you use RFC 5011". If so, then maybe proper use >> of RFC 5011 (such as when to assume that a zone is *really* being >> signed, not just for practice) should be part of >> draft-ietf-dnsop-rfc4641bis. > > > I think you have a point. I can imagine that such section would be about > putting trust in a trust-anchor and the considerations that apply there. > Shooting from the hip here are some considerations: > > - When to trust a trust anchor: > * whenever the zone-owner declares that a key is ready to be used as > trust-anchor and > * whenever you, as validator administrator, are satisfied that the > rollover procedure > is documented clearly enough and you are confident you can track the > rollovers > > - When not to trust a trust anchor: > * when a key appears in a zone and there is no trusted out-of-band > communication that > such key is in production. > > - Cases where transitive trust may work: > * when a trusted third party validates the key-zone binding, the > production > readiness, and tracks the keys. (ITAR) > * when copying zone data from a parental zone to which you have a DNS > trust relation. > I can see rare cases why you would want to establish a trust-anchor > in the middle of > a chain of trust that is in place. But if you follow this route I'm > not sure about if > there is a fate sharing argument that renders this sort of > configuration useless. > > Obvious missing points? > > I've added this as open issue: > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration > > > --Olaf > > > ------------------------------------------------------------------------ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScKFgg8yVCPsQCW5AQJnCQf/QLbLjp85Zp7zQPvb9z8KGdeCz1O52rGz boMljfuOcnvk9iZy/pZNnbyUT0msMX64FryiS4CGXNTZ/Qeen8+87KqTSI85/Wpo 2r/vebDrZU2MUNIbgYc/4Jxi0vtutsBrpT3Vvop8TpxL5DcfuMs8O1edbDcC/dw5 AFkzb1a1SF3GRxjnJTWzv3KsYHABGCfyT9d25bRc02iJgXjZqwxrpI2fDPG+Dog0 PnQ1Mc15vbQYO1g7PFBHv08qyAfuqfuUXGqy7aUB+c+SCZcveHRe4/wEVMw6mGtv UCJHzNldYcDJrhwyN9HLbsVKxTDf+W1Y/5TSNk9iCVELvMtOpziELg== =E+dk -----END PGP SIGNATURE----- From tglassey@earthlink.net Thu Mar 19 11:54:18 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C0428C0FE for ; Thu, 19 Mar 2009 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyT3CVGuYbtD for ; Thu, 19 Mar 2009 11:54:16 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9A56C28C0E8 for ; Thu, 19 Mar 2009 11:54:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=boc/LNKXhJz3cB9EQIX2VRxdJLsakgd05KKcwb/v6a0f7vOLUOoUO+AAkG+Hv90z; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LkNOP-00013m-9X; Thu, 19 Mar 2009 14:55:01 -0400 Message-ID: <49C29503.7000506@earthlink.net> Date: Thu, 19 Mar 2009 11:54:59 -0700 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Matthijs Mekking References: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> <49C28582.8030605@nlnetlabs.nl> In-Reply-To: <49C28582.8030605@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b33192d424f0041fec37c9e516f9633a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 18:54:18 -0000 Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Also, RFC 5011 may adapt key rollover practices. > In short this means that when a key may be removed because it is > considered dead, it should stay in the zone for one RRSIG TTL more with > its REVOKED bit set before removing it from the zone. This way, rfc5011 > enabled resolvers can update their trust anchors in-band. > This is more about use policy than anything else. By the way since I personally coined the term "Trust Anchor" in PKIX towards the late-1990's and got hammered by Dr. Kent for it, maybe I should get to tell you what it means... Trust anchors by pure definition are reliable points of reference which intended to make the content they anchor portable, that is to say comparable in a like manner to other like-anchored content. That said, a timestamp of any number of types can be a trust-anchor as can a token created through some form of cryptographic process. Scary thought that eh? Todd Glassey > Matthijs > > Olaf Kolkman schreef: > >> On 16 mrt 2009, at 16:34, Paul Hoffman wrote: >> >> >>> It feels like a lot of DNSSEC questions these days are being answered >>> by "that's covered if you use RFC 5011". If so, then maybe proper use >>> of RFC 5011 (such as when to assume that a zone is *really* being >>> signed, not just for practice) should be part of >>> draft-ietf-dnsop-rfc4641bis. >>> >> I think you have a point. I can imagine that such section would be about >> putting trust in a trust-anchor and the considerations that apply there. >> Shooting from the hip here are some considerations: >> >> - When to trust a trust anchor: >> * whenever the zone-owner declares that a key is ready to be used as >> trust-anchor and >> * whenever you, as validator administrator, are satisfied that the >> rollover procedure >> is documented clearly enough and you are confident you can track the >> rollovers >> >> - When not to trust a trust anchor: >> * when a key appears in a zone and there is no trusted out-of-band >> communication that >> such key is in production. >> >> - Cases where transitive trust may work: >> * when a trusted third party validates the key-zone binding, the >> production >> readiness, and tracks the keys. (ITAR) >> * when copying zone data from a parental zone to which you have a DNS >> trust relation. >> I can see rare cases why you would want to establish a trust-anchor >> in the middle of >> a chain of trust that is in place. But if you follow this route I'm >> not sure about if >> there is a fate sharing argument that renders this sort of >> configuration useless. >> >> Obvious missing points? >> >> I've added this as open issue: >> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration >> >> >> --Olaf >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEVAwUBScKFgg8yVCPsQCW5AQJnCQf/QLbLjp85Zp7zQPvb9z8KGdeCz1O52rGz > boMljfuOcnvk9iZy/pZNnbyUT0msMX64FryiS4CGXNTZ/Qeen8+87KqTSI85/Wpo > 2r/vebDrZU2MUNIbgYc/4Jxi0vtutsBrpT3Vvop8TpxL5DcfuMs8O1edbDcC/dw5 > AFkzb1a1SF3GRxjnJTWzv3KsYHABGCfyT9d25bRc02iJgXjZqwxrpI2fDPG+Dog0 > PnQ1Mc15vbQYO1g7PFBHv08qyAfuqfuUXGqy7aUB+c+SCZcveHRe4/wEVMw6mGtv > UCJHzNldYcDJrhwyN9HLbsVKxTDf+W1Y/5TSNk9iCVELvMtOpziELg== > =E+dk > -----END PGP SIGNATURE----- > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From paul.hoffman@vpnc.org Thu Mar 19 14:28:17 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CD73A6969 for ; Thu, 19 Mar 2009 14:28:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8dWxxuRCdhT for ; Thu, 19 Mar 2009 14:28:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8DAF03A687E for ; Thu, 19 Mar 2009 14:28:16 -0700 (PDT) Received: from [10.20.30.158] (c-67-180-135-22.hsd1.ca.comcast.net [67.180.135.22]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JLSxTj056064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Mar 2009 14:29:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <49C29503.7000506@earthlink.net> References: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> <49C28582.8030605@nlnetlabs.nl> <49C29503.7000506@earthlink.net> Date: Thu, 19 Mar 2009 14:28:57 -0700 To: dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 21:28:17 -0000 As much as I hate to engage in threads like this, I would like to make a factual correction. At 11:54 AM -0700 3/19/09, TSG wrote: >By the way since I personally coined the term "Trust Anchor" in PKIX towards the late-1990's This is provably false. Carlisle Adams was the first to use the term on the PKIX mailing list in January of 1998. --Paul Hoffman, Director --VPN Consortium From tglassey@earthlink.net Thu Mar 19 16:20:54 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E139A3A69A3 for ; Thu, 19 Mar 2009 16:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7MmZO+24QCW for ; Thu, 19 Mar 2009 16:20:54 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 070933A688C for ; Thu, 19 Mar 2009 16:20:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Z0qX0/kRJ42SqKWfFMGaeaJXX1H9ENYYgvC+xO08p9Ine/kEIAvi/Px09hLVEIyZ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LkRYR-0000Xw-9t; Thu, 19 Mar 2009 19:21:39 -0400 Message-ID: <49C2D381.8020702@earthlink.net> Date: Thu, 19 Mar 2009 16:21:37 -0700 From: Todd Glassey CISM CIFI User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Hoffman References: <9C353262-B54C-44D8-AA73-75181364B91A@NLnetLabs.nl> <49C28582.8030605@nlnetlabs.nl> <49C29503.7000506@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7952633496016658cc8c78a0ae1673261e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 23:20:55 -0000 Paul Hoffman wrote: > As much as I hate to engage in threads like this, I would like to make a factual correction. > > At 11:54 AM -0700 3/19/09, TSG wrote: > >> By the way since I personally coined the term "Trust Anchor" in PKIX towards the late-1990's >> > This is provably false. I am glad you said that in print Paul - you are wrong. I coined the term... PERIOD. > Carlisle Adams was the first to use the term on the PKIX mailing list in January of 1998. > > --Paul Hoffman, Director > --VPN Consortium > Yeah - no.... actually somewhere between 16 and 24 months earlier Steve read me the riot act for "coining new marketing terms inside PKIX" he threatened to remove me if I didnt stop too as I recall and that was its first public use in the PKI community. What was really freaking cool was how stupid Carlilise's use of my terminology made Kent look. There are actually three terms - and they come from a work I did on business process work-flows in 1993. Trust Anchor - An aspect of a trust process used to correlate the content of the process to some other reference data-point. This could include any data-points or controls which provide positive reporting as to authentications, non-repudiation and synchronization Portable Trust - Trust Models which can be represented as discrete policy models. The key source of portability in content records would be timestamps by the way. Verifiable Relation - The item that the Trust Anchor provides the anchoring of. From an Audit perspective Trust Anchors are used to create reliable reporting models which are used to implement the social requirements for human processes in a digital context. That's a bunch of hand waving for systems and controls which implement human processes as they would be in the real world, but in a cyber-context. Content which is anchored is made portable, that is comparable to any other content processed through a child or like process. Sorry... Todd Glassey > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From bortzmeyer@nic.fr Fri Mar 20 09:44:43 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B603A6B8C for ; Fri, 20 Mar 2009 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaD9cfEHMoxm for ; Fri, 20 Mar 2009 09:44:43 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id F158B3A682D for ; Fri, 20 Mar 2009 09:44:42 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7779D1C015F for ; Fri, 20 Mar 2009 17:40:28 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 72BED1C0159 for ; Fri, 20 Mar 2009 17:40:28 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 671E4A1D9BD for ; Fri, 20 Mar 2009 17:40:28 +0100 (CET) Date: Fri, 20 Mar 2009 17:40:28 +0100 From: Stephane Bortzmeyer To: IETF DNSOP WG Message-ID: <20090320164028.GA4107@nic.fr> References: <20090318163132.GA8085@unknown.office.denic.de> <49C12342.9070006@earthlink.net> <6.2.5.6.2.20090318145913.0303a900@resistor.net> <49C17B7D.80305@earthlink.net> <49C18C29.1010502@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C18C29.1010502@earthlink.net> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:44:43 -0000 On Wed, Mar 18, 2009 at 05:04:57PM -0700, TSG wrote a message of 55 lines which said: > So a Medical Records Purveyor in the UK puts their data online for > Doctor's to download. And because of the BGP4 Routing Flap the MitM > Attack is seamlessly functional. [...] This is a specific hack where > DNS would be used effectively to kill someone by redirecting the > Medical Records Bureau [...] I'm not an expert in people killing but this method seems quite convoluted and I hope that the IETF will standardize something much simpler and which works ("Rough consensus and running weapons"). From dougb@dougbarton.us Sat Mar 21 22:43:57 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAF43A6885 for ; Sat, 21 Mar 2009 22:43:57 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZWABAMCDAhj for ; Sat, 21 Mar 2009 22:43:56 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 50A2B3A67EA for ; Sat, 21 Mar 2009 22:43:56 -0700 (PDT) Received: (qmail 19566 invoked by uid 399); 22 Mar 2009 05:44:43 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Mar 2009 05:44:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49C5D04A.8020603@dougbarton.us> Date: Sat, 21 Mar 2009 22:44:42 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: IETF DNSOP WG References: <20090318163132.GA8085@unknown.office.denic.de> In-Reply-To: <20090318163132.GA8085@unknown.office.denic.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 05:43:57 -0000 Peter Koch wrote: > Dear WG, > > this is to initiate a working group last call on > > "Requirements for Management of Name Servers for the DNS" > draft-ietf-dnsop-name-server-management-reqs-02.txt > > ending Friday, 2009-04-10, 23:59 UTC. The tools site gives easy access to > diffs and such under > . I've read the draft at the URL above and am generally supportive of its moving forward. I noticed the following nits. Assuming that the grammatical issues could be sorted out down the road I would not object to the draft moving forward without the other issues I mention below being addressed. hope this helps, Doug Abstract: "not a interoperable" should be "not an ..." Abstract: The last paragraph is awkward. Perhaps: This document discusses the requirements of a management system for DNS name servers and can be used as a shopping list of needed features for such a system. 1. Introduction: "not a interoperable" should be "not an ..." 1. Introduction: The awkward paragraph from the Abstract is repeated here. 2.1.1 Zone Size Constraints: The last sentence is awkward. Perhaps: Both deployment scenarios are common. 2.1.3 Configuration Data Volatility: Same as 2.1.1 above. 2.1.5 Common Data Model: "is needed for of the operations discussion" the "of" there should be removed 3.1.1 Needed Control Operations The ability to do a reload on an individual zone should probably be mentioned here. From tglassey@earthlink.net Sun Mar 22 11:01:42 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932B63A69D4 for ; Sun, 22 Mar 2009 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y99nq3fRFBJs for ; Sun, 22 Mar 2009 11:01:41 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id AA2153A689D for ; Sun, 22 Mar 2009 11:01:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jMwwgqdfAJ430i9NnojBqLFzYzmwr1Brmcpq4dd4KmnHgks9Azth9aaQq8CTcM7U; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LlS0E-00080S-E6; Sun, 22 Mar 2009 14:02:30 -0400 Message-ID: <49C67D34.60606@earthlink.net> Date: Sun, 22 Mar 2009 11:02:28 -0700 From: Todd Glassey CISM CIFI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Doug Barton References: <20090318163132.GA8085@unknown.office.denic.de> <49C5D04A.8020603@dougbarton.us> In-Reply-To: <49C5D04A.8020603@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bfc476159a6da1b665aa7a9f0e31cf11350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:01:42 -0000 Doug Barton wrote: > Peter Koch wrote: > >> Dear WG, >> >> this is to initiate a working group last call on >> >> "Requirements for Management of Name Servers for the DNS" >> draft-ietf-dnsop-name-server-management-reqs-02.txt >> >> ending Friday, 2009-04-10, 23:59 UTC. The tools site gives easy access to >> diffs and such under >> . >> > > I've read the draft at the URL above and am generally supportive of > its moving forward. I noticed the following nits. Assuming that the > grammatical issues could be sorted out down the road I would not > object to the draft moving forward without the other issues I mention > below being addressed. > > > hope this helps, > > Doug > > > Abstract: "not a interoperable" should be "not an ..." > Abstract: The last paragraph is awkward. Perhaps: > This document discusses the requirements of a management > system for DNS name servers and can be used as a shopping > list of needed features for such a system. > As long as you are being nit picky the phrase "(Domain Name Service) name servers" reads kinda funny. How about just DNS Resolver's or something like that? T. > 1. Introduction: "not a interoperable" should be "not an ..." > 1. Introduction: The awkward paragraph from the Abstract is repeated here. > 2.1.1 Zone Size Constraints: The last sentence is awkward. Perhaps: > Both deployment scenarios are common. > 2.1.3 Configuration Data Volatility: Same as 2.1.1 above. > 2.1.5 Common Data Model: "is needed for of the operations discussion" > the "of" there should be removed > 3.1.1 Needed Control Operations > The ability to do a reload on an individual zone should probably be > mentioned here. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From dougb@dougbarton.us Sun Mar 22 11:39:50 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531443A6B80 for ; Sun, 22 Mar 2009 11:39:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGjYAQ2QUwMh for ; Sun, 22 Mar 2009 11:39:49 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 4C9F43A67F3 for ; Sun, 22 Mar 2009 11:39:49 -0700 (PDT) Received: (qmail 29041 invoked by uid 399); 22 Mar 2009 18:40:37 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Mar 2009 18:40:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49C68623.3050302@dougbarton.us> Date: Sun, 22 Mar 2009 11:40:35 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Todd Glassey CISM CIFI References: <20090318163132.GA8085@unknown.office.denic.de> <49C5D04A.8020603@dougbarton.us> <49C67D34.60606@earthlink.net> In-Reply-To: <49C67D34.60606@earthlink.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:39:50 -0000 Todd Glassey CISM CIFI wrote: > Doug Barton wrote: >> Abstract: The last paragraph is awkward. Perhaps: >> This document discusses the requirements of a management >> system for DNS name servers and can be used as a shopping >> list of needed features for such a system. >> > > As long as you are being nit picky the phrase "(Domain Name Service) > name servers" reads kinda funny. How about just DNS Resolver's or > something like that? That part of the sentence I quoted verbatim from the existing text in an effort to minimize the changes. I think removing "DNS" from the original further improves the text along the lines you pointed out. Good catch, Doug From bortzmeyer@nic.fr Sun Mar 22 12:47:09 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635B03A6806 for ; Sun, 22 Mar 2009 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrDdYifJ4uFW for ; Sun, 22 Mar 2009 12:47:08 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 6EC193A67ED for ; Sun, 22 Mar 2009 12:47:08 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B88AB1C015C; Sun, 22 Mar 2009 20:42:55 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B39031C0135; Sun, 22 Mar 2009 20:42:55 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A7A147B0036; Sun, 22 Mar 2009 20:42:55 +0100 (CET) Date: Sun, 22 Mar 2009 20:42:55 +0100 From: Stephane Bortzmeyer To: Alexander Mayrhofer Message-ID: <20090322194255.GA1195@nic.fr> References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304141357.GA17627@nic.fr> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:47:09 -0000 On Wed, Mar 04, 2009 at 03:13:57PM +0100, Stephane Bortzmeyer wrote a message of 27 lines which said: > For instance, should the ABNF allow fully-numeric top-level domain > names? There is no *technical* reason to ban them. Wow, I never noticed this Web page: http://cr.yp.to/djbdns/dot-local.html which is interesting to read in the light of the discussion on fully-numeric top-level domain names :-) From sm@resistor.net Sun Mar 22 13:42:53 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501B83A6A3D for ; Sun, 22 Mar 2009 13:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oQPXJjC0oFG for ; Sun, 22 Mar 2009 13:42:52 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 5B1503A6A21 for ; Sun, 22 Mar 2009 13:42:52 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n2MKhViv013029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Mar 2009 13:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1237754619; x=1237841019; bh=9n+TC3MpdV5p0bhUrvyvOD9T5fqvFTnkolKb1/Kbcq8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=13x2eo3tWzDGkRoKIXvMpiZRj4JCbdGz69psp4dlUE2UNN0sTDfR6PdtaOhLSuXda 9wtX6IwQgyGEpvXu7HUaRdWieee1Wq7FrRDDWo8PhltAu6vpkh4xlGS7JcG+eJbrZV eOCKJmcWxJ2K0gOGp6AIQpUI9ArVSdnU249DLi74= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=L7FDBusEqql4y2YebYVKGEhvBVuE5VHBEDo4gtROnxwQkGd7UfU+uJNDbB9MnTcmK JpJBOTVW8nMeonswU4xTyVpUnWCj19xFGTff/SS4/he7/MpPFFvvr8yfQUmmAR+VK71 PLLiDPtQao+Ggdnw94USShXSRUSoIhPURu41Mn0= Message-Id: <6.2.5.6.2.20090322125244.028cefd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Mar 2009 13:42:39 -0700 To: IETF DNSOP WG From: SM In-Reply-To: <20090318163132.GA8085@unknown.office.denic.de> References: <20090318163132.GA8085@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 20:42:53 -0000 At 09:31 18-03-2009, Peter Koch wrote: >this is to initiate a working group last call on > > "Requirements for Management of Name Servers for the DNS" > draft-ietf-dnsop-name-server-management-reqs-02.txt From the Abstract: "Management of name servers for the Domain Name Service (DNS) has traditionally been done using vendor-specific monitoring, configuration and control methods." Shouldn't that be Domain Name System? That's what DNS stands for in RFC 1034. "Domain Name Service" could be changed throughout the document to "Domain Name System". There are several places in the document where "DNS service" is used. In Section 2.1.2 "Finding and managing large quantities of name servers would be a useful feature of the resulting management solution." I suggest "a large number" instead of large quantities". Regards, -sm From tglassey@earthlink.net Mon Mar 23 07:40:20 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117063A6838 for ; Mon, 23 Mar 2009 07:40:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GbHUfnmZ-Rv for ; Mon, 23 Mar 2009 07:40:19 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E14BB3A67DD for ; Mon, 23 Mar 2009 07:40:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bW/MqtKOxwTDADCT410aoXgb9VJNCoJ8e3eZCVWVvAXJq5uSNlMhALxcS1q9DuS0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.101]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LllKt-0007GP-83; Mon, 23 Mar 2009 10:41:07 -0400 Message-ID: <49C79F83.3010101@earthlink.net> Date: Mon, 23 Mar 2009 07:41:07 -0700 From: Todd Glassey CISM CIFI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <22ocwh8o8p.fsf@zaptop.autonomica.net> <8BC845943058D844ABFC73D2220D466508071495@nics-mail.sbg.nic.at> <20090304141357.GA17627@nic.fr> <20090322194255.GA1195@nic.fr> In-Reply-To: <20090322194255.GA1195@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798a0c5b29416014149b192efd096a09a8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: Alexander Mayrhofer , dnsop@ietf.org Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:40:20 -0000 Stephane Bortzmeyer wrote: > On Wed, Mar 04, 2009 at 03:13:57PM +0100, > Stephane Bortzmeyer wrote > a message of 27 lines which said: > > >> For instance, should the ABNF allow fully-numeric top-level domain >> names? There is no *technical* reason to ban them. >> > > Wow, I never noticed this Web page: > > http://cr.yp.to/djbdns/dot-local.html > > which is interesting to read in the light of the discussion on > fully-numeric top-level domain names :-) > really good catch Stephane! TSG// > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From peter@denic.de Tue Mar 24 14:55:39 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB1328C2E9 for ; Tue, 24 Mar 2009 14:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jEsmx8oY-oO for ; Tue, 24 Mar 2009 14:55:38 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 2B09728C20F for ; Tue, 24 Mar 2009 14:55:38 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LmEbk-0003fq-5q; Tue, 24 Mar 2009 22:56:28 +0100 Received: from localhost by x27.adm.denic.de with local id 1LmEYi-00078L-Dp; Tue, 24 Mar 2009 22:53:20 +0100 Date: Tue, 24 Mar 2009 22:53:20 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20090324215320.GC24642@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] Final agenda for today's DNSOP meeting X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:55:39 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear WG, find attached a copy of today's final agenda, including pointers to the uploaded presentations. An online version is available at Regards, Peter --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dnsop74.txt" ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 74, Minneapolis Location: Hilton San Francisco, Continental 4 Date: Tuesday, 24 March 2009 Time: 15:20 - 17:00 (UTC-8) (// ancp, keyprov, krb-wg, mext, mmox, rtgarea, speermint Chairs: Rob Austein Peter Koch Jabber: xmpp:dnsop@jabber.ietf.org WG URL: http://tools.ietf.org/wg/dnsop/ Material: https://datatracker.ietf.org/meeting/74/materials.html Version: $Revision: 1.4 $ ----------------------------------------------------------------------------- 1) Administrivia [chairs][ 5 min][15:20] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min][15:25] - RFCs published RFC 5358 "Preventing Use of Recursive Nameservers in Reflector Attacks" - Internet-Drafts in RFC Editor Queue - NONE - - I-Ds at the IESG - NONE - - I-Ds in or past WGLC - draft-ietf-dnsop-reverse-mapping-considerations-06.txt post WGLC, EXPIRED, minor edits needed, to be sent to IESG - draft-ietf-dnsop-respsize-11.txt EXPIRED - draft-ietf-dnsop-default-local-zones-08.txt write-up in progress - draft-ietf-dnsop-as112-under-attack-help-help-02.txt write-up in progress - draft-ietf-dnsop-name-server-management-reqs-02.txt WGLC ends 3) WG Charter [chairs][ 0 min][15:30] - no news, skipped - 4) Active Drafts [chairs][25 min][15:30] 4.0) draft-ietf-dnsop-resolver-priming-01.txt [ 0 min] EXPIRED, incorporation of feedback pending draft-ietf-dnsop-as112-ops-02.txt revived, awaiting WGLC 4.1) draft-ietf-dnsop-dnssec-trust-anchor-03.txt [ 5 min] Awaiting WGLC 4.2) draft-ietf-dnsop-rfc4641bis-01.txt [20 min] [Olaf Kolkman] Discussion of Open Issues 5) Current & New Topics [chairs][30 min][15:55] 5.1) draft-morris-dnsop-dnssec-key-timing-00.txt [15 min] [Johan Ihren] 5.2) draft-liman-tld-names-00.txt [15 min] [Lars-Johan Liman] 6) Other (non WG) Internet-Drafts [chairs][ 0 min][16:25] - NONE - 7) I/O with other WGs [chairs][15 min][16:25] behave) draft-bagnulo-behave-dns64-02.txt [Andrew Sullivan] hiprg) draft-ponomarev-hip-hit2ip-03.txt [Oleg Ponomarev] mif) "Multiple Interfaces BOF", Thursday, 1510 - 1610 6man) RFC 3484bis, draft-chown-addr-select-considerations-02.txt Today, Tuesday, 1710-1810 8) A.O.B. [N.N.][10 min][16:40] {please identify issues in advance} 8.0) DNSSEC, IXFR and redundant signers [Joe Gersch] ----------------------------------------------------------------------------- --zYM0uCDKw75PZbzx-- From ajs@shinkuro.com Tue Mar 24 17:03:00 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258CE3A6880 for ; Tue, 24 Mar 2009 17:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=1.895, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jkPOy5NAZEu for ; Tue, 24 Mar 2009 17:02:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 51F933A63CB for ; Tue, 24 Mar 2009 17:02:59 -0700 (PDT) Received: from crankycanuck.ca (dhcp-10f0.meeting.ietf.org [130.129.16.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 961B12FEA05E for ; Wed, 25 Mar 2009 00:03:49 +0000 (UTC) Date: Tue, 24 Mar 2009 20:03:47 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20090325000346.GD8765@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [DNSOP] More solicitation for feedback on dns64 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:03:00 -0000 Dear colleagues, Despite the speed with which I went through the dns64 issue, there is in fact something in this that could really do with some attention. Again, this isn't a WG document and really needs to be discussed in behave, but I'll make a more detailed plea here now that you all heard me talking really fast saying something. Suppose that we have a security-aware, non-validating stub behind a translator. On query it sets DO and does not set CD. The translator is a validating, recursive resolver that also performs the translation function (a "translating validator", for short). The general principle is that we MUST validate before translation. So, the translating validator queries for the AAAA record, doesn't get one, queries for the A record, and gets one with all the DNSSEC data necessary for validation. The translating validator successfully validates the A record. Now, it translates. To perform the translation, it moves the A record to the additional section, strips off all the RRSIG and other DNSSEC-relevant data, synthesizes the AAAA record to match the A record, and sets the AD bit. It then ships the resulting response to the stub. The question is whether that's broken in such a way that it will break any clients. In particular, are there clients that will get heartburn if AD is set on a response when there's otherwise apparently no security data in the response? For background, the extant -02 draft doesn't do it as outlined above. It said instead that the translating validator MUST NOT set the AD bit, because the answer being returned isn't actually validatable. The counter-argument, raised by Dave Thaler, is that RFC 4035 allows the validator to set AD if it knows it can trust the answer (and of course, the validator can know that: it validated the response from the DNS, and it knows the prefix it is using). In addition, Dave reports that there is an implementation that uses the AD bit, in a secure-last-hop context, as a boolean security flag such that applications can make different decisions based on whether AD was set. So he has a use case that he wants supported. Any feedback welcome. As I said at the mic, discussion is really going on in behave; I'll happily take direct feedback as well. Thanks for your time today. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ondrej.sury@nic.cz Tue Mar 24 17:03:17 2009 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2523A68A7 for ; Tue, 24 Mar 2009 17:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, GB_I_LETTER=-2, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1glwxvB4n5Jc for ; Tue, 24 Mar 2009 17:03:16 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id C76CA3A68A4 for ; Tue, 24 Mar 2009 17:03:15 -0700 (PDT) Received: by bwz17 with SMTP id 17so2462949bwz.37 for ; Tue, 24 Mar 2009 17:04:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.116.205 with SMTP id n13mr7610413faq.103.1237939446597; Tue, 24 Mar 2009 17:04:06 -0700 (PDT) In-Reply-To: <20090311161752.GI18975@shinkuro.com> References: <20090309170441.GH16211@shinkuro.com> <20090310092721.GA631@nic.fr> <20090311134546.GA18975@shinkuro.com> <558a39a60903110756s11eb7b8csc6d912167835693a@mail.gmail.com> <20090311153651.GG18975@shinkuro.com> <558a39a60903110844y3d448bb5pf5b366a5465c7ef0@mail.gmail.com> <20090311161752.GI18975@shinkuro.com> Date: Tue, 24 Mar 2009 17:04:06 -0700 Message-ID: From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:03:17 -0000 Sorry for not following this discussion earlier and thus rising thing already discussed at mic :-(... On Wed, Mar 11, 2009 at 9:17 AM, Andrew Sullivan wrote: > On Wed, Mar 11, 2009 at 11:44:54PM +0800, James Seng wrote: >> >> >>