From d3e3e3@gmail.com Sun Jul 1 16:28:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10F21F8897 for ; Sun, 1 Jul 2012 16:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YbUWLt1S9l6 for ; Sun, 1 Jul 2012 16:28:09 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id D624421F8692 for ; Sun, 1 Jul 2012 16:28:08 -0700 (PDT) Received: by yhfq11 with SMTP id q11so4491597yhf.15 for ; Sun, 01 Jul 2012 16:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9YtvYYDZRJlLyn7DMTaqAveUg66+r5Wznb0LrPipgic=; b=mvcF80a4G9jXUjWVbze8q8npQ8euLn3t92Nz29jvsUPIFdPG/7ReJQdJLRkkgeFsij Z+4WGZJvcksC5YBXi/kvuOpU9lArzxtT4+fAahOJ5EMw4zGtn5UZwzFFQdWWf4LXavty TE+QmqgSvub2WBbx7gAWMQpAplzxBxMDYCa3HGeNNi+FykwSCKzboo0WpDChyTPcx0xB dds1lL0MG66RiGnHwYGn8/ZCUzAMh/3me7rYczqEiYAirzEhewRNFmm/W3VhQWXJnCfN OALL70Sg3zrPNa8fqhRMcrFajhaqNcLo9Qin+x2/8fJLG67AOeTbdqBzWobdkQazv72P I+kA== Received: by 10.50.194.200 with SMTP id hy8mr5848876igc.58.1341185291402; Sun, 01 Jul 2012 16:28:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Sun, 1 Jul 2012 16:27:46 -0700 (PDT) In-Reply-To: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> From: Donald Eastlake Date: Sun, 1 Jul 2012 19:27:46 -0400 Message-ID: To: Michael Sheldon Content-Type: text/plain; charset=ISO-8859-1 Cc: "dnsext@ietf.org" , Olafur Gudmundsson Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 23:28:10 -0000 On Wed, Jun 13, 2012 at 12:00 PM, Michael Sheldon wrote: > In section 3.1: > "There are currently five QTYPEs > assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR." > > I would consider changing "* (ALL)" to "* (ALL/ANY)" > > While officially type 255 is * ALL, just about every implementation I've > ever seen refers to it as ANY. If no one objects, I wouldn't mind making the above change. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Michael Sheldon > Dev-DNS Services > GoDaddy.com > >> -------- Original Message -------- >> Subject: [dnsext] WGLC: RFC6195bis IANA guidance >> From: Olafur Gudmundsson >> Date: Mon, June 11, 2012 10:43 am >> To: "" >> >> >> Dear colleagues >> >> This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ >> June 28'th 2012. >> http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02 >> >> This document addresses known flaws in the RFC6195 (see appendix A). >> >> Please review the document and post a note that you have reviewed the >> document we need a minimum of 5 reviewers. >> >> Olafur & Andrew >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From d3e3e3@gmail.com Mon Jul 2 07:22:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7A21F8690 for ; Mon, 2 Jul 2012 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-xjUIcWkTMT for ; Mon, 2 Jul 2012 07:22:30 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89121F8636 for ; Mon, 2 Jul 2012 07:22:30 -0700 (PDT) Received: by yhp26 with SMTP id 26so5725164yhp.26 for ; Mon, 02 Jul 2012 07:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QXpeJsJBHlDhMaCWms7lOY20G9N9aCkCIjFN1qbzNZ4=; b=C3HceIr+2Ri6QnfXPpq42VhGZTyIV/YR5eoA6rZliXiBy5mWVeDD2vzed4YmZ8asxS lsJSNMjbum+2W5YGY0u7IrLKmjkcXEf7dD58hq5kQwPUnr5kX2gqOpkK9Qy+6o8OL2Sy wuo9jAoo1MBkKWZbx/ElngV9yCtaS43ykll5vPbNj2/TN0gw4J7KQbb8SuGh/gykPx5h q5ydaD47pm1ouRaChqMy65Z9Cre5k+umzbi8OY+A0GnSs6DS90/CZ8ZRiGye/z2aTQvP 6iqrGs6nzu4aNd0SgIzU+dlP4oERGH8DMm72GUlAXMaqwmB2/NyHYj63Ph2u346tpaAt uA1Q== Received: by 10.50.213.106 with SMTP id nr10mr5432505igc.58.1341238955086; Mon, 02 Jul 2012 07:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 2 Jul 2012 07:22:14 -0700 (PDT) In-Reply-To: References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> From: Donald Eastlake Date: Mon, 2 Jul 2012 10:22:14 -0400 Message-ID: To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DNSEXT WG Subject: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 14:22:31 -0000 [cc'ed to DNSEXT with permission] Hi Mark, Thanks for the comments. Stuff in curly braces ("{ }") is stuff I've added. On Thu, Jun 28, 2012 at 11:04 PM, Mark Andrews wrote: > > {existing draft:} > The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful > only in queries or only in responses, depending on the bit. However, > some DNS implementations copy the query header as the initial value > of the response header without clearing bits. Thus, any attempt to > use a "query" bit with a different meaning in a response or to define > a query meaning for a "response" bit is dangerous, given existing > implementation. Such meanings may only be assigned by a Standards > Action. > > {proposed:} > The AA, TC, RD, RA, AD[1], and CD bits are each theoretically meaningful > only in queries or only in responses, depending on the bit. Only > RD and CD are expected to be copied from the query to the response > however some DNS implementations copy all the query header as the > initial value of the response header. Thus, any attempt to > use a "query" bit with a different meaning in a response or to define > a query meaning for a "response" bit is dangerous, given existing > implementation. Such meanings may only be assigned by a Standards > Action. > > [1] AD is expected to have seperate but related meanings in both the > query and response. OK. I don't have a problem with the proposed text except that I'd like to know where the expectation that AD has a meaning in queries comes from... > 2.2 OpCode Assignment > > Status is reserved in RFC 1035 but not behaviour is defined. OK. I can add "Although the Status OpCode is reserved in [RFC1035], its behavior has not been specified." > 2.3 RCODE Assignment > > NOTAUTH is also overloaded and you need to look at the TSIG > result code to work out which. If the TSIG result code > is zero or does not exist then it is not authoritative. > > "Not authoritative" [RFC 2136] > "Not authorised" [RFC 2845] OK. I can change the table entry to point to a note right after the RCODE table saying that. > RRTYPE assignments need to say something about the rdata format > no longer being subject to change. Its not for reserving a code > point as it will be coded into implementations. I'm not quite certain what you mean above. That the RDATA format approved as part of the RRTYPE assignment process can never be changed later? Seems reasonable that it can't be changed unilaterally. But I don't see why you shouldn't be able to change it by going through the process again. Maybe there is some field or value or flag or something that is just wrong or can't possibly work or whatever that wasn't spotted when the application was initially processed. Or maybe even for problems not that bad. Of course, you could always get another RRTYPE but that has problems as well, with having to query both, etc. There are various engineering trade offs so I don't think a flat prohibition on any changes, if that is what you are saying, is reasonable. Question B.1 on the RRTYPE Application temple already asks if it is a new assignment or a modification of a previously assigned RRTYPE. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ray.Bellis@nominet.org.uk Mon Jul 2 08:01:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C5821F86B7 for ; Mon, 2 Jul 2012 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6apqIfqamth6 for ; Mon, 2 Jul 2012 08:01:22 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id C71E121F869E for ; Mon, 2 Jul 2012 08:01:20 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=ex1goMAEl1s27LXE9Dk8c9vgvzvhHM7dMZTwXkI0HVZQRmGixNe7jB0o aPLMYIzxAQME5bsl2pvi/Ycx/qSyknLWrAlO7FPwFtnn6cza3hMCzGr9E 265D2v26yCHkE+k; 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=1341241286; x=1372777286; 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=20Bellis=20 |Subject:=20Re:=20[dnsext]=20=20WGLC:=20RFC6195bis=20IANA =20guidance|Date:=20Mon,=202=20Jul=202012=2015:01:23=20+0 000|Message-ID:=20|To:=20Donald=20Eastlake=20|CC:=20IETF=20DNSEXT=20WG=20 |MIME-Version:=201.0|In-Reply-To:=20 |References:=20<20120613090016.205a61dff9fc1684c258b27466 2bb912.d2ce8b95d9.wbe@email00.secureserver.net>=0D=0A=20< CAF4+nEGbZavii4p_km2kRik-5B2RB19wJ2TFZJ-tSbX-x=3DNh6A@mai l.gmail.com>=0D=0A=20; bh=J0NhO0R37ynF8OHnjbWg+tDOEXIADC8hvy/dSxO7yPk=; b=CEiS22V4D4Be9BuimBupqqxWBo7lKrB3gfoQ1WN7ldhapo1wGSOT2c5r a2fUEksDRqZWxd0epJeQNL6WJYOQ2ozR5wz/ddkBYsS1cQIRiiOQkkNM3 IZXypz2trvcQ+NR; X-IronPort-AV: E=Sophos;i="4.77,512,1336345200"; d="asc'?scan'208";a="33926964" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 02 Jul 2012 16:01:25 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 2 Jul 2012 16:01:24 +0100 From: Ray Bellis To: Donald Eastlake Thread-Topic: [dnsext] WGLC: RFC6195bis IANA guidance Thread-Index: AQHNWF4s3xJg3Qoey0ugyI5K8sEGMZcWBZeA Date: Mon, 2 Jul 2012 15:01:23 +0000 Message-ID: References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail=_80D10950-0301-47A2-B1B1-F309ED6D7600"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 15:01:22 -0000 --Apple-Mail=_80D10950-0301-47A2-B1B1-F309ED6D7600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Jul 2012, at 15:22, Donald Eastlake wrote: > OK. I don't have a problem with the proposed text except that I'd like > to know where the expectation that AD has a meaning in queries comes > from... It's in dnssec-bis-updates, and implemented in BIND at least a couple of = years ago (as far as I can remember). Ray --Apple-Mail=_80D10950-0301-47A2-B1B1-F309ED6D7600 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAk/xt8MACgkQ+cr96znPxN6yhwCdEL39priKU/6b01MKxGsIDynk 4HwAniztcACqSKezAQ+Oryjjr3cc2WrG =jo+J -----END PGP SIGNATURE----- --Apple-Mail=_80D10950-0301-47A2-B1B1-F309ED6D7600-- From d3e3e3@gmail.com Mon Jul 2 08:09:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16AE21F8698 for ; Mon, 2 Jul 2012 08:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hikD4SCEqFVz for ; Mon, 2 Jul 2012 08:09:02 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3221F85AA for ; Mon, 2 Jul 2012 08:09:01 -0700 (PDT) Received: by yenq13 with SMTP id q13so4658892yen.31 for ; Mon, 02 Jul 2012 08:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=npbX+5MgxeC90rF2U73m6Xxcb6172QbACCrdukQdlZA=; b=YpzWFldXCSAxm9ypzhafWXnXBYAoNl4yACiPqMLTJEKpYVC9KqDJjUZNDAZv+rMAQQ /KYhFl6PSoOHPqHW8GurNCi6SsnjDUAJU1Y+BPGh5r58isYdcUGxYM/g+WGOZ7RfX8pa 3UHT3BxT/HHWA4TvknlRDkxLOPFeVmacOVJTWw+sC71zCvU9wfVH671kv6Roxag04R4c 7AEluFdyNNUh8tv5zwxTv69gvinQ/E+jXrDcnvwwiTge9865+wxQqYyUIy3mSWKQiXBc 0x0AZVsnyaWgcqk18KtMZ806Y4xiiAPXsTwy8pb/Xm+1BYhTcFerZtMzvpjIxbAA+AVy Xugw== Received: by 10.50.196.232 with SMTP id ip8mr7651121igc.50.1341241746984; Mon, 02 Jul 2012 08:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 2 Jul 2012 08:08:46 -0700 (PDT) In-Reply-To: References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> From: Donald Eastlake Date: Mon, 2 Jul 2012 11:08:46 -0400 Message-ID: To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 15:09:03 -0000 OK, I'll add appropriate text and a reference to that RFC-to-be. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jul 2, 2012 at 11:01 AM, Ray Bellis wrote: > > On 2 Jul 2012, at 15:22, Donald Eastlake wrote: > >> OK. I don't have a problem with the proposed text except that I'd like >> to know where the expectation that AD has a meaning in queries comes >> from... > > It's in dnssec-bis-updates, and implemented in BIND at least a couple of years ago (as far as I can remember). > > Ray > > From internet-drafts@ietf.org Mon Jul 2 19:18:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0746121F8565; Mon, 2 Jul 2012 19:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrJqAMDhUAgs; Mon, 2 Jul 2012 19:18:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63621F850F; Mon, 2 Jul 2012 19:18:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703021834.802.77326.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 19:18:34 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 02:18:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : Donald E. Eastlake Filename : draft-ietf-dnsext-rfc6195bis-03.txt Pages : 22 Date : 2012-07-02 Abstract: This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-rfc6195bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Mon Jul 2 19:28:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC45521F84FF for ; Mon, 2 Jul 2012 19:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eAUqzlH2Jky for ; Mon, 2 Jul 2012 19:28:01 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50F2E21F84F3 for ; Mon, 2 Jul 2012 19:28:01 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5295601ggn.31 for ; Mon, 02 Jul 2012 19:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=fYxOubEBFZLu8KYxeTy9dF4uEuUDKaVNlV8+2ZDc7ig=; b=rOACWtu8nFSfwoguPPFrXiM1JogUlsVTnFjzvxGFWybdbUoXnT2Gtv3xP0fpC0yK7P nXZD+MsOvXrbMVeEdPgk/f+Jr4FBh1d0ZQgsywCitL8rMS4NREcrWcOB7kkTYGXo61/8 ZyrrVGwIzl+W4xp+oFJAZkSOE4AA8SzuiWqzB/fF5JNpBhOTJ+5HBw4MTz5ue8/u3xNz uJFpRN8PmKomOkO/pGI+5s8W7RleZn3lDN135VgGYNPal5J1w35aaJYMYfqyao2wf0AS +xvRcDLWUn4A3eu6W5eYoluQGCQcqy8Mv6a7bJ4quRxtTImLh17qp50b3AE64hE8T7y8 j1qA== Received: by 10.42.89.72 with SMTP id f8mr7563517icm.33.1341282487514; Mon, 02 Jul 2012 19:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 2 Jul 2012 19:27:47 -0700 (PDT) In-Reply-To: <20120703021834.802.77326.idtracker@ietfa.amsl.com> References: <20120703021834.802.77326.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 2 Jul 2012 22:27:47 -0400 Message-ID: To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 02:28:02 -0000 Hi, I have attempted to incorporate the comment resolutions so far. Please tell me if you think I've messed up as I can back out or modify changes. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jul 2, 2012 at 10:18 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Domain Name System (DNS) IANA Considerations > Author(s) : Donald E. Eastlake > Filename : draft-ietf-dnsext-rfc6195bis-03.txt > Pages : 22 > Date : 2012-07-02 > > Abstract: > This document specifies Internet Assigned Number Authority (IANA) > parameter assignment considerations for the allocation of Domain Name > System (DNS) resource record types, CLASSes, operation codes, error > codes, DNS protocol message header bits, and AFSDB resource record > subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, > and 3597. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-03 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsext-rfc6195bis-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From marka@isc.org Tue Jul 3 07:14:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87621F8823 for ; Tue, 3 Jul 2012 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf6X3xZxIBC9 for ; Tue, 3 Jul 2012 07:13:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68421F8754 for ; Tue, 3 Jul 2012 07:13:42 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 788705F984C; Tue, 3 Jul 2012 14:13:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (CPE-124-177-138-97.lns3.woo.bigpond.net.au [124.177.138.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4CCC5216C33; Tue, 3 Jul 2012 14:13:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 45D4D222DC10; Wed, 4 Jul 2012 00:13:31 +1000 (EST) To: Donald Eastlake From: Mark Andrews References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> In-reply-to: Your message of "Mon, 02 Jul 2012 10:22:14 -0400." Date: Wed, 04 Jul 2012 00:13:31 +1000 Message-Id: <20120703141331.45D4D222DC10@drugs.dv.isc.org> Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:14:04 -0000 In message , Donald Ea stlake writes: > [cc'ed to DNSEXT with permission] > > Hi Mark, > > Thanks for the comments. Stuff in curly braces ("{ }") is stuff I've added. > > On Thu, Jun 28, 2012 at 11:04 PM, Mark Andrews wrote: > > > > {existing draft:} > > The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful > > only in queries or only in responses, depending on the bit. However, > > some DNS implementations copy the query header as the initial value > > of the response header without clearing bits. Thus, any attempt to > > use a "query" bit with a different meaning in a response or to define > > a query meaning for a "response" bit is dangerous, given existing > > implementation. Such meanings may only be assigned by a Standards > > Action. > > > > {proposed:} > > The AA, TC, RD, RA, AD[1], and CD bits are each theoretically meaningful > > only in queries or only in responses, depending on the bit. Only > > RD and CD are expected to be copied from the query to the response > > however some DNS implementations copy all the query header as the > > initial value of the response header. Thus, any attempt to > > use a "query" bit with a different meaning in a response or to define > > a query meaning for a "response" bit is dangerous, given existing > > implementation. Such meanings may only be assigned by a Standards > > Action. > > > > [1] AD is expected to have seperate but related meanings in both the > > query and response. > > OK. I don't have a problem with the proposed text except that I'd like > to know where the expectation that AD has a meaning in queries comes > from... > > > 2.2 OpCode Assignment > > > > Status is reserved in RFC 1035 but not behaviour is defined. > > OK. I can add "Although the Status OpCode is reserved in [RFC1035], > its behavior has not been specified." > > > 2.3 RCODE Assignment > > > > NOTAUTH is also overloaded and you need to look at the TSIG > > result code to work out which. If the TSIG result code > > is zero or does not exist then it is not authoritative. > > > > "Not authoritative" [RFC 2136] > > "Not authorised" [RFC 2845] > > OK. I can change the table entry to point to a note right after the > RCODE table saying that. > > > RRTYPE assignments need to say something about the rdata format > > no longer being subject to change. Its not for reserving a code > > point as it will be coded into implementations. DANE thought that they had a code point that they could change the internal structure about at will by going through the allocation process. They needed to be disavowed of this notion. This should not happen again. > I'm not quite certain what you mean above. That the RDATA format > approved as part of the RRTYPE assignment process can never be changed > later? Seems reasonable that it can't be changed unilaterally. But I > don't see why you shouldn't be able to change it by going through the > process again. Because once you have code in the field that knows the internal structure of a RR changing that structure breaks those implementations that have implemented the RR. > Maybe there is some field or value or flag or something > that is just wrong or can't possibly work or whatever that wasn't > spotted when the application was initially processed. Or maybe even > for problems not that bad. Of course, you could always get another > RRTYPE but that has problems as well, with having to query both, etc. > There are various engineering trade offs so I don't think a flat > prohibition on any changes, if that is what you are saying, is > reasonable. Question B.1 on the RRTYPE Application temple already asks > if it is a new assignment or a modification of a previously assigned > RRTYPE. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Tue Jul 3 07:45:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CF321F8458 for ; Tue, 3 Jul 2012 07:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6UvF7lqAOyJ for ; Tue, 3 Jul 2012 07:45:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8821F87A2 for ; Tue, 3 Jul 2012 07:45:46 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q63EjnPS034979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2012 07:45:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120703141331.45D4D222DC10@drugs.dv.isc.org> Date: Tue, 3 Jul 2012 07:45:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <20120703141331.45D4D222DC10@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1278) Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:45:51 -0000 On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote: >>> RRTYPE assignments need to say something about the rdata format >>> no longer being subject to change. Its not for reserving a code >>> point as it will be coded into implementations. >=20 > DANE thought that they had a code point that they could change the > internal structure about at will by going through the allocation > process. They needed to be disavowed of this notion. This should > not happen again. Mark's sneering is one way to look at it. Another is that, with an = RRtype in a mature draft that labelled as TBD, implementers will just = pick one and then eventually squat on it, screwing up both the registry = and implementations. Standards-track protocols can be changed all the way through IESG = review. Those changes could in fact change the internal structure of the = data covered in an RRtype. This leaves exactly two choices: - Force Internet-Drafts to keep their RRtype as TBD all the way until = the IESG passes the Internet-Draft to the RFC Editor - Allow WGs and document authors to request RRtype assignment earlier in = the process and know that there might be a change based on technical = review of the document Pick one. --Paul Hoffman= From nweaver@icsi.berkeley.edu Tue Jul 3 08:05:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875DA21F86DE for ; Tue, 3 Jul 2012 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DictPgTCWcr for ; Tue, 3 Jul 2012 08:05:29 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E859221F8848 for ; Tue, 3 Jul 2012 08:05:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id ECE762C4003; Tue, 3 Jul 2012 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3OAzDaAx9gtP; Tue, 3 Jul 2012 08:05:36 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id AA28A2C4002; Tue, 3 Jul 2012 08:05:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20120703141331.45D4D222DC10@drugs.dv.isc.org> Date: Tue, 3 Jul 2012 08:05:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09F9497E-099B-4880-8E17-55A63633D775@icsi.berkeley.edu> References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <20120703141331.45D4D222DC10@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1278) Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:05:29 -0000 On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote: >> I'm not quite certain what you mean above. That the RDATA format >> approved as part of the RRTYPE assignment process can never be = changed >> later? Seems reasonable that it can't be changed unilaterally. But I >> don't see why you shouldn't be able to change it by going through the >> process again. >=20 > Because once you have code in the field that knows the internal > structure of a RR changing that structure breaks those implementations > that have implemented the RR.=20 So by this logic, why not just advise every future RTYPE requests = include, as the first byte, a version number field, allowing all future = RTYPE requests to enable updates without needing to register a new = RTYPE? And DANE can get this already: Any changes to the certificate associate = data should have a new usage number, and usage number 255 means that the = first octet of the otherwise opaque certificate association data is the = extended usage type. Voila, problem solved. From d3e3e3@gmail.com Tue Jul 3 08:32:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7223B11E8152 for ; Tue, 3 Jul 2012 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHPKly3YRxVP for ; Tue, 3 Jul 2012 08:32:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1411E8151 for ; Tue, 3 Jul 2012 08:32:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4742100vbb.31 for ; Tue, 03 Jul 2012 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=7G4OQZNCdOHeRWawm3O0vFiSsCm0UKbCjE46dm+0Hgg=; b=imir5cssYWewFmtEVxG2jUhZNtVBKbpybcYR2tqXKDRbteS9QSFYkT7SCZSQXYXphw Nd2UMR0IoteMLAhi1E1rq3sxKplcWXHJ6nwI0OJ5GLtkwzBNVX4Z7wbKsDzil1ZPmgVH Jfnt4v6fWLWGzHoVWroXsZmaxvyWSs2m7Ac4vdKGsPJ6Rt/ISRSShgl+v6nOlnusU3kg rMiBAij0JPVX1QlyQrzO7Qvrad8DSuORQTbi4nqF547IiUlJfQqZHW0xkQ0ZEvArJS6u QL7ExFZ5pojkasuMC2vNhOWizctLowcF9idRatTG+LG15pEC9pGyN2Bp3i+iT9vASseB GhbA== Received: by 10.42.89.72 with SMTP id f8mr9012037icm.33.1341329531833; Tue, 03 Jul 2012 08:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Tue, 3 Jul 2012 08:31:51 -0700 (PDT) In-Reply-To: <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <20120703141331.45D4D222DC10@drugs.dv.isc.org> <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> From: Donald Eastlake Date: Tue, 3 Jul 2012 11:31:51 -0400 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:32:05 -0000 Hi, On Tue, Jul 3, 2012 at 10:45 AM, Paul Hoffman wrote: > On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote: > >>>> RRTYPE assignments need to say something about the rdata format >>>> no longer being subject to change. Its not for reserving a code >>>> point as it will be coded into implementations. >> >> DANE thought that they had a code point that they could change the >> internal structure about at will by going through the allocation >> process. They needed to be disavowed of this notion. This should >> not happen again. > > Mark's sneering is one way to look at it. Another is that, with an RRtype in a mature draft that labelled as TBD, implementers will just pick one and then eventually squat on it, screwing up both the registry and implementations. > > Standards-track protocols can be changed all the way through IESG review. Those changes could in fact change the internal structure of the data covered in an RRtype. This leaves exactly two choices: > > - Force Internet-Drafts to keep their RRtype as TBD all the way until the IESG passes the Internet-Draft to the RFC Editor But then the IESG can pull a draft back for the RFC Editor queue and change it. Or, after it issues as an RFC, they can cause it to be obsoleted by a revised RFC. Barring another Kobe revolution or the like, the locus of power in the IETF is the IESG. Anyone who believes some IANA Considerations in an RFC for an IETF parameter are more powerful than the IESG is a fooling themselves. However, notwithstanding that, the IANA Considerations should be something reasonable that has WG consensus. > - Allow WGs and document authors to request RRtype assignment earlier in the process and know that there might be a change based on technical review of the document To avoid squatting and the like and consistent with the idea of making it generally easier to get an RRTYPE code point, I think this is the way to go. There is already provision in the application template to indicate whether you are submitted for a new RRTYPE or the modification of an existing RRTYPE. I think about the best we can do is to add some language like: "An RRTYPE Allocation Template, indicating that it is for the modification of an RRTYPE, MUST be submitted when any material change is made to an existing RRTYPE specification. This includes any changes that occur in the processing of an internet-draft after initial RRTYPE allocation and before RFC publication." > Pick one. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > --Paul Hoffman From paul.hoffman@vpnc.org Thu Jul 5 07:55:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1C221F86E4 for ; Thu, 5 Jul 2012 07:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFFXPNQcF425 for ; Thu, 5 Jul 2012 07:55:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91321F8734 for ; Thu, 5 Jul 2012 07:55:39 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q65EtogD074592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jul 2012 07:55:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <4FD62E4E.4020007@ogud.com> Date: Thu, 5 Jul 2012 07:55:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD62E4E.4020007@ogud.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:55:44 -0000 On Jun 11, 2012, at 10:43 AM, Olafur Gudmundsson wrote: > This message starts a 2 week WGLC for RFC6195bis ending at midnight = UTZ June 28'th 2012. > http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02 >=20 > This document addresses known flaws in the RFC6195 (see appendix A). >=20 > Please review the document and post a note that you have reviewed the = document we need a minimum of 5 reviewers. I apologize for getting to this so late, but I also note that I might be = just the fifth reviewer... The document is mostly fine. However, I have one major issue with it: it's not clear what IANA is = supposed to do with it. There is a *lot* of text in this document that = is repetition of the RFCs, as well as some important historical notes = that are not currently in RFCs or in the IANA registry. When this = document is finished, is IANA supposed to change each sub-registry to = include the text from the relevant section of this RFC? If not, why is = that text in this "IANA Considerations" document? I can see a few ways = forward here: a) Explicitly tell IANA what additional material from this document = should go in each sub-registry b) Tell IANA to put at the top of the registry something like "In order = to understand this registry, you need to understand the underlying RFCs = and the history of the registries. In order to do that, you should read = BCP XXX" with a link to this document My preference is the latter, but people might want the former to make it = harder for readers of the registry to miss the relevant stuff. There = might be other ideas as well. Two other issues that should be clarified: - Can anyone subscribe to the dns-rrtype-applications@ietf.org mailing = list to see the applications come in? It is *not* listed on the page at = . - At the end of 2.2, what does "as modified by [RFC4020]" mean? Is is = supposed to be "as described in [RFC4020]"? --Paul Hoffman= From Ed.Lewis@neustar.biz Thu Jul 5 11:57:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591A511E80BA for ; Thu, 5 Jul 2012 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8VdJvYOpw0n for ; Thu, 5 Jul 2012 11:57:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 921B721F86EA for ; Thu, 5 Jul 2012 11:57:12 -0700 (PDT) Received: from jeng-lt61.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q65IvL17013967; Thu, 5 Jul 2012 14:57:24 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.170] by jeng-lt61.cis.neustar.com (PGP Universal service); Thu, 05 Jul 2012 14:57:25 -0400 X-PGP-Universal: processed; by jeng-lt61.cis.neustar.com on Thu, 05 Jul 2012 14:57:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1340433313.43178.YahooMailClassic@web161701.mail.bf1.yahoo.com> <21DEB429-D133-4C34-BFA8-F057E50977A8@cisco.com> Date: Thu, 5 Jul 2012 14:57:17 -0400 To: DNSEXT Working Group From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-870607851==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] "knowing A root key" was Re: draft-diao-aip-dns X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 18:57:13 -0000 --============_-870607851==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:32 -0700 6/29/12, Nicholas Weaver wrote: >... DNSSEC, in practice, relies on knowing A root key. Not really. The set of trust anchors a validator use is a local policy consideration. RFC 4035 4.4. Configured Trust Anchors 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... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! --============_-870607851==_ma============ Content-Type: text/html; charset="us-ascii" "knowing A root key" was Re: [dnsext] draft-diao-aip-dns
At 8:32 -0700 6/29/12, Nicholas Weaver wrote:

>... DNSSEC, in practice, relies on knowing A root key.

Not really.  The set of trust anchors a validator use is a local policy consideration.

RFC 4035

4.4.  Configured Trust Anchors

   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...

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
--============_-870607851==_ma============-- From rwfranks@gmail.com Thu Jul 5 15:06:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06711E80AA for ; Thu, 5 Jul 2012 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb8R-KataMXL for ; Thu, 5 Jul 2012 15:06:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5E21F85F3 for ; Thu, 5 Jul 2012 15:06:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6313840vbb.31 for ; Thu, 05 Jul 2012 15:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UiNC3FHY5B+Y7K5O1Cz6j4DKmv32qIz+6wEl2xOOm6Q=; b=csznDYGeegLHveAkP46IgZ80Dp0fGvj+5bHV6HhtBDhxgfhu/c8QxrFlHM2zN6G/qO CVSACC+RGauTtxfof/cQTIz4NQiAv2BFg8GMYvEc+uxLzy8cp7JJ8NgAC2AMR0GvHVri xuFUV8uhKmoS0EQslKEAwXPg3sLxH/oK2tmCe6o/Eq6eDGTxWYC6F+0UbntgkKVH+Fcz 5GfLMRltUikfeejdJ07agb7WeAbGzTy3TFVDrgwAJcPdkoRqgq4p9qR0uHegGBbehJAu JHZp4gUeeAdeCGanZOBbXaTjwp/SmU5Aels5JazN1T+gOa+5j5BtkhqC7QL3aN3wcubw XLrg== Received: by 10.220.219.137 with SMTP id hu9mr11744046vcb.4.1341525985829; Thu, 05 Jul 2012 15:06:25 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.52.157.162 with HTTP; Thu, 5 Jul 2012 15:06:05 -0700 (PDT) In-Reply-To: References: <4FD62E4E.4020007@ogud.com> From: Dick Franks Date: Thu, 5 Jul 2012 23:06:05 +0100 X-Google-Sender-Auth: IRpkDK9p-E0ozxZ__tw_eJN1IDY Message-ID: To: Donald Eastlake Content-Type: text/plain; charset=UTF-8 Cc: dnsext@ietf.org, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 22:06:12 -0000 Donald, My apologies for late response. On 22 June 2012 19:10, Donald Eastlake wrote: ... >> [3.1 paragraph 4] >> and [3.2 paragraph 4] >> >> Regexes: >> >> [A-Z][A-Z0-9\-]*[A-Z0-9] >> >> (TYPE|CLASS)(0|[1-9][0-9]*) >> >> could be simplified to: >> >> [A-Z][A-Z0-9]* >> >> (TYPE|CLASS)[0-9]* > > That's not simplification, that's change. A simplification of the underlying production rule for RRTYPE mnemonics, which inevitably flows through to the regex. > I believe that internal hyphens should be allowed within RRTYPE and > CLASS mnemonics. We do not know what future mnemonics or sets of > mnemonics will be required. Better to remain more flexible here. There appears to be no real-world requirement to do so. The justification for flexibility would best be debated if/when some genuine need arises. The collective decision of a multitude of worthy authors, over a span of more than 25 years, has been to treat RRTYPE mnemonics as simple Algol/Fortran style identifiers, even when some clearly had the opportunity to do otherwise. The regex should be tightened to make explicit a de facto standard observed by prominent members of the IETF engineering community. The unmodified regex has the unintended and undesirable consequence that it allows the IANA tail to wag the IETF dog. > I have no problem with making the Regex 2 exclusion slightly stronger > so going with your changed Regex 2 is fine with me. + --Dick From d3e3e3@gmail.com Thu Jul 5 15:36:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D87411E80C4 for ; Thu, 5 Jul 2012 15:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJaEMVAWNgEb for ; Thu, 5 Jul 2012 15:36:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F111E80BD for ; Thu, 5 Jul 2012 15:36:50 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15740552obb.31 for ; Thu, 05 Jul 2012 15:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=6iTMs00zmuQBvaCoS4dSy9t4irJhQlVPP0NxPhFU8/o=; b=0elwwUDvN4zPNDQxBCciuZAZYagjuJaqZzYEfdsvwXs/0cMcHNHLSZZj71exjRLd2/ 6aUkWImH7QYRWTcuWh51wsqpxbh1ea8L+jHW1ZTeaxGbqJmyw5BxS+pFMIiinNfN9o6E dPvEQvmFqxsNNjPRXMvKrAWozLJhaQTB7G+Geq6LGSk83PGxIOB4O35FzCvpTx8idSgD Jei3/AG4flf1Hpb6LM7CkK+Nf1EwTL+/xtZCI2xKse6004N6lMwkmmtXKI9siG8SVWtQ qi6Qg4tTb284b1lsceDc3JT9UFS9ibplot3VfDESNmMV8MDLUWOGkd5suQyVNIp0rebX W8jw== Received: by 10.182.231.6 with SMTP id tc6mr23213585obc.63.1341527824562; Thu, 05 Jul 2012 15:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.70.137 with HTTP; Thu, 5 Jul 2012 15:36:44 -0700 (PDT) In-Reply-To: References: <4FD62E4E.4020007@ogud.com> From: Donald Eastlake Date: Thu, 5 Jul 2012 18:36:44 -0400 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 22:36:51 -0000 Hi Paul, On Thu, Jul 5, 2012 at 10:55 AM, Paul Hoffman wrote= : > On Jun 11, 2012, at 10:43 AM, Olafur Gudmundsson wrote: > >> This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ = June 28'th 2012. >> http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02 >> >> This document addresses known flaws in the RFC6195 (see appendix A). >> >> Please review the document and post a note that you have reviewed the do= cument we need a minimum of 5 reviewers. > > I apologize for getting to this so late, but I also note that I might be = just the fifth reviewer... The document is mostly fine. > > However, I have one major issue with it: it's not clear what IANA is supp= osed to do with it. There is a *lot* of text in this document that is repet= ition of the RFCs, as well as some important historical notes that are not = currently in RFCs or in the IANA registry. When this document is finished, = is IANA supposed to change each sub-registry to include the text from the r= elevant section of this RFC? If not, why is that text in this "IANA Conside= rations" document? I can see a few ways forward here: > > a) Explicitly tell IANA what additional material from this document shoul= d go in each sub-registry > > b) Tell IANA to put at the top of the registry something like "In order t= o understand this registry, you need to understand the underlying RFCs and = the history of the registries. In order to do that, you should read BCP XXX= " with a link to this document > > My preference is the latter, but people might want the former to make it = harder for readers of the registry to miss the relevant stuff. There might = be other ideas as well. I also favor the latter. > Two other issues that should be clarified: > > - Can anyone subscribe to the dns-rrtype-applications@ietf.org mailing li= st to see the applications come in? It is *not* listed on the page at . I don't think anyone else can subscribe. IANA is required to monitor that list and presumably whoever IANA wants are the subscribers. > - At the end of 2.2, what does "as modified by [RFC4020]" mean? Is is sup= posed to be "as described in [RFC4020]"? The way I always thought of it, "Standards Action" is defined in [RFC5226]. [RFC4020] ("Early IANA Allocation of Standards Track Code Points") then modifies that definition to permit early allocation under specific circumstances. The "as modified by [RFC4020]" is how I've always written this. For example, it is how this is expressed in RFC 6195 and its predecessor RFC 5395. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From d3e3e3@gmail.com Thu Jul 5 15:54:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18D11E80ED for ; Thu, 5 Jul 2012 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOcgakA3cNYg for ; Thu, 5 Jul 2012 15:54:20 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4F11E80D9 for ; Thu, 5 Jul 2012 15:54:19 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15760552obb.31 for ; Thu, 05 Jul 2012 15:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gFxkCynu5GECoJNp5Lg0IRcGIaxrSthNzfrgbZJLiwg=; b=P0YySTRTpNDooqHTHeau2V1+LcILuCnjYrhYL3wxSbrwL4CHpH14pU3BOofQdR93D3 X/Yutf8MGJ75vFQR20Ifr5snSSWyuPPwFmlM3z2xh2qD9xp/h9sRyw8MlV6GVCGIXoHU G613rz69+IeQZO4KV6l6KZMX9uzFp1b5LjkGZ9qSOWAMugSUstAOhj8SpwCyeK4CBK2I WErHJEbhFQg8cZ0egl/F23IS4CfLSHjKdsMYT89gzDTh5BJVUnWuA9iW+N0lrCwVIAvu 5uQZ3wkwPcoZ/KPkL6chkDuzFsUEK7QP6da7fb+7qZwzfNmzDaSyM6aO4SrAWwCSl9Hc hhgg== Received: by 10.182.50.98 with SMTP id b2mr23139512obo.28.1341528874001; Thu, 05 Jul 2012 15:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.70.137 with HTTP; Thu, 5 Jul 2012 15:54:13 -0700 (PDT) In-Reply-To: References: <4FD62E4E.4020007@ogud.com> From: Donald Eastlake Date: Thu, 5 Jul 2012 18:54:13 -0400 Message-ID: To: Dick Franks Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 22:54:22 -0000 Hi Dick, On Thu, Jul 5, 2012 at 6:06 PM, Dick Franks wrote: > Donald, > > My apologies for late response. > > > On 22 June 2012 19:10, Donald Eastlake wrote: > ... >>> [3.1 paragraph 4] >>> and [3.2 paragraph 4] >>> >>> Regexes: >>> >>> [A-Z][A-Z0-9\-]*[A-Z0-9] >>> >>> (TYPE|CLASS)(0|[1-9][0-9]*) >>> >>> could be simplified to: >>> >>> [A-Z][A-Z0-9]* >>> >>> (TYPE|CLASS)[0-9]* >> >> That's not simplification, that's change. > A simplification of the underlying production rule for RRTYPE mnemonics, > which inevitably flows through to the regex. OK, it is a simplification of the RegEx, but one I don't agree with. >> I believe that internal hyphens should be allowed within RRTYPE and >> CLASS mnemonics. We do not know what future mnemonics or sets of >> mnemonics will be required. Better to remain more flexible here. > > There appears to be no real-world requirement to do so. The justification for > flexibility would best be debated if/when some genuine need arises. > > The collective decision of a multitude of worthy authors, over a span of more > than 25 years, has been to treat RRTYPE mnemonics as simple Algol/Fortran > style identifiers, even when some clearly had the opportunity to do otherwise. > > The regex should be tightened to make explicit a de facto standard observed > by prominent members of the IETF engineering community. We appear to disagree and no one else has spoken on this. If this were a brand new draft/standard, I'm not sure how this would be settled. However, it is not. IANA Considerations for DNS has explicitly permitted hyphens in these mnemonics since 2008 (and were silent on this point before that) and a mnemonic with a hyphen was allocated earlier and remains in the registry today. Under these circumstances, I believe the RegEx should not be changed to prohibit hyphens. > The unmodified regex has the unintended and undesirable consequence that > it allows the IANA tail to wag the IETF dog. I don't understand that at all. The applicant normally selects the mnemonic and, if the applicant doesn't, then the Expert does. IANA does not. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> I have no problem with making the Regex 2 exclusion slightly stronger >> so going with your changed Regex 2 is fine with me. > + > > > --Dick From ajs@anvilwalrusden.com Thu Jul 5 16:45:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3711E808A for ; Thu, 5 Jul 2012 16:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4bOzu0FOq8h for ; Thu, 5 Jul 2012 16:45:35 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9A11E80F4 for ; Thu, 5 Jul 2012 16:45:35 -0700 (PDT) Received: from crankycanuck.ca (unknown [199.119.129.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 08DEB8A031 for ; Thu, 5 Jul 2012 23:45:48 +0000 (UTC) Date: Thu, 5 Jul 2012 19:45:47 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120705234547.GG1245@crankycanuck.ca> References: <4FD62E4E.4020007@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 23:45:36 -0000 I'm not speaking in any sort of chair "here's-the-rules" role, but I am speaking with the background of what I've learned as a chair of this WG over time. On Thu, Jul 05, 2012 at 06:54:13PM -0400, Donald Eastlake wrote: > a brand new draft/standard, I'm not sure how this would be settled. > However, it is not. IANA Considerations for DNS has explicitly > permitted hyphens in these mnemonics since 2008 (and were silent on > this point before that) and a mnemonic with a hyphen was allocated > earlier and remains in the registry today. Under these circumstances, > I believe the RegEx should not be changed to prohibit hyphens. I completely agree with Donald's point here. If we are going to make a substantive change to the rules along these lines (and one incompatible with existing registrations), the bar for adoption will be _much_ higher than if we do not do that. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msheldon@godaddy.com Thu Jul 5 17:09:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7923D21F8707 for ; Thu, 5 Jul 2012 17:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW7meW1mtGmx for ; Thu, 5 Jul 2012 17:09:55 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id C0F6121F8705 for ; Thu, 5 Jul 2012 17:09:55 -0700 (PDT) Received: (qmail 11970 invoked from network); 6 Jul 2012 00:10:07 -0000 Received: from unknown (HELO gem-wbe37.prod.mesa1.secureserver.net) (64.202.189.51) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 6 Jul 2012 00:10:07 -0000 Received: (qmail 5181 invoked by uid 99); 6 Jul 2012 00:10:07 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.144 User-Agent: Workspace Webmail 5.6.22 Message-Id: <20120705171005.205a61dff9fc1684c258b274662bb912.6aa0bf2606.wbe@email00.secureserver.net> From: "Michael Sheldon" To: "IETF DNSEXT WG" Date: Thu, 05 Jul 2012 17:10:05 -0700 Mime-Version: 1.0 Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 00:09:56 -0000 > From: Nicholas Weaver =0A> Date: Tue, July 03,= 2012 8:05 am=0A>=0A> So by this logic, why not just advise every future RT= YPE requests include, as the first byte,=0A> a version number field, allowi= ng all future RTYPE requests to enable updates without needing=0A> to regis= ter a new RTYPE?=0A=0AThis is intriguing, though would only be needed by re= latively complex=0Arecord types...=0A=0AStill, this would have to be define= d as part of the original record=0Aspecification, along with the procedures= for defining new versions, and=0Aprocedures for resolvers, servers and app= lications when encountering=0Aversions they do not understand/support.=0A= =0AAnd then again, how many times would this have been useful?=0A=0AMichael= Sheldon=0ADev-DNS Services=0AGoDaddy.com=0A From marka@isc.org Fri Jul 6 02:38:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C90621F86B2 for ; Fri, 6 Jul 2012 02:38: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-5L+eQbuq9F for ; Fri, 6 Jul 2012 02:38:04 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0921F864D for ; Fri, 6 Jul 2012 02:38:03 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6211BC95E1; Fri, 6 Jul 2012 09:38:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (CPE-123-211-135-142.lnse3.woo.bigpond.net.au [123.211.135.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CAF73216C36; Fri, 6 Jul 2012 09:37:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AED242238832; Fri, 6 Jul 2012 18:59:16 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <20120703141331.45D4D222DC10@drugs.dv.isc.org> <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> In-reply-to: Your message of "Tue, 03 Jul 2012 07:45:50 MST." <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> Date: Fri, 06 Jul 2012 18:59:16 +1000 Message-Id: <20120706085916.AED242238832@drugs.dv.isc.org> Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 09:38:04 -0000 In message <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org>, Paul Hoffman writes: > On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote: > > >>> RRTYPE assignments need to say something about the rdata format > >>> no longer being subject to change. Its not for reserving a code > >>> point as it will be coded into implementations. > >=20 > > DANE thought that they had a code point that they could change the > > internal structure about at will by going through the allocation > > process. They needed to be disavowed of this notion. This should > > not happen again. > > Mark's sneering is one way to look at it. For a expert to be able to evaluate a RR type definition it needs to be stable. No expert can say a RR type definintion can be said to be safe / good if it is still subject to change. > Another is that, with an = > RRtype in a mature draft that labelled as TBD, implementers will just = > pick one and then eventually squat on it, screwing up both the registry = > and implementations. Then pick a private type for testing. Been there, done that. It is not impossible to do. > Standards-track protocols can be changed all the way through IESG = > review. Those changes could in fact change the internal structure of the = > data covered in an RRtype. This leaves exactly two choices: And that ends up with a total review of the impact of the new structure has on the old implementations. This level of review doesn't happen between I-D revisions. > - Force Internet-Drafts to keep their RRtype as TBD all the way until = > the IESG passes the Internet-Draft to the RFC Editor > > - Allow WGs and document authors to request RRtype assignment earlier in = > the process and know that there might be a change based on technical = > review of the document > > Pick one. > > --Paul Hoffman= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From roy@nominet.org.uk Fri Jul 6 04:44:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AB421F8776 for ; Fri, 6 Jul 2012 04:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqNJHJQp2u4H for ; Fri, 6 Jul 2012 04:43:59 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8B64721F8745 for ; Fri, 6 Jul 2012 04:43:57 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=t4P9jTXPm2W5B9Ot6+HJgcNipQA1/Rci84GOOF4/wYJQPfAWHL+DwQXG SnDfBOojRMawp6wFsGtZjonLO9LtZOxWARR0hR5nRsF/XN7fvRfIO2hsY ZGebMQss7ec3CO3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1341575055; x=1373111055; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20I LNP=20RRTYPEs=20review=20-=20result=20[IANA=20#561079] |Date:=20Fri,=206=20Jul=202012=2011:44:10=20+0000 |Message-ID:=20<99DC3EA9-EBBB-4D91-8C0B-4AC097E3BA8E@nomi net.org.uk>|To:=20"dnsext@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<4e82ab9e-6b0f-4b29-a11f-ad4a3a2e b68b>|In-Reply-To:=20|References:=20; bh=o1S49In7UUYv2yjLXLxuTiFiWcIMH1USnO5hJwGfSTc=; b=lnkPDbrVJeAUuv+gjOx2blhjim55id1N2lAJVc/JW9cibvRRoNoaw11v G5OWpY2oQ16Hj24PXGVpxli01GcVQrtVDBYpy561dnZCoRlARv6wAUODv +oYMOmHHU60K4op; X-IronPort-AV: E=Sophos;i="4.77,537,1336345200"; d="scan'208";a="41400587" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 06 Jul 2012 12:44:12 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 6 Jul 2012 12:44:11 +0100 From: Roy Arends To: "dnsext@ietf.org" Thread-Topic: ILNP RRTYPEs review - result [IANA #561079] Thread-Index: AQHNW2yohhY5yqT2t0eWThyYzrP15A== Date: Fri, 6 Jul 2012 11:44:10 +0000 Message-ID: <99DC3EA9-EBBB-4D91-8C0B-4AC097E3BA8E@nominet.org.uk> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4e82ab9e-6b0f-4b29-a11f-ad4a3a2eb68b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnsext] ILNP RRTYPEs review - result [IANA #561079] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 11:44:00 -0000 Dear Colleagues, This message ends the review process for the ILNP RRTYPEs. According to my judgment the requests meet RFC6195 at both requirements of section 3.1.1 and none of section 3.1.2 and should be accepted. I will work with the editors to address Tony Finch' editorial remarks. Thank you, Warmly, Roy Arends Best Regards, On Jun 13, 2012, at 11:00 PM, Roy Arends wrote: > Dear Colleagues, >=20 > Below is a completed template requesting new RRTYPE assignments under the= procedures of RFC6195. >=20 > This message starts a 3 weeks period for an expert-review of the DNS RRTY= PE parameter allocations for ILNP specified in http://www.ietf.org/id/draft= -irtf-rrg-ilnp-dns-05.txt >=20 > If you have comments regarding this request please post them here before = July 5th 18:00 UTC. >=20 > Best Regards, > Roy Arends >=20 > DNS RRTYPE PARAMETER ALLOCATION TEMPLATE >=20 > When ready for formal consideration, this template is > to be submitted to IANA for processing by emailing the > template to dns-rrtype-applications@ietf.org. >=20 > A. Submission Date: To be determined. >=20 > B. Submission Type: > [X] New RRTYPE >=20 > C. Contact Information for submitter: > Name: R. Atkinson > Email Address: rja.lists@gmail.com > International telephone number: unlisted > Other contact handles: >=20 > D. Motivation for the new RRTYPE application? >=20 > Support for an experimental set of IP extensions > that replace the concept of an "IP Address" with > distinct "Locator" and "Identifier" values. >=20 > E. Description of the proposed RR type. >=20 > Please see: >=20 > http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt >=20 > for a full description. >=20 > F. What existing RRTYPE or RRTYPEs come closest to filling > that need and why are they unsatisfactory? >=20 > There is no RRTYPE that fulfils the need due to the > new semantics of Locator and Identifier values. >=20 > The AAAA record combines both Locator and Identifier, > so has significantly different semantics than having > separate L64 and NID record values. The AAAA record also > lacks scalability and flexibility in the context of the > experimental protocol extensions that will use the NID > and L64 records, as any valid NID record value for a node > can be used on the wire with any valid L64 record value > for the same node. >=20 > The CNAME record is closest conceptually to an LP > record, but a CNAME is a node name referral scheme, > while the LP record is indicating that the given node > has the same routing prefix as some other domain name, > but does not necessarily have any other values that are > the same. >=20 > Lastly, the AAAA and CNAME RR Types lack a Preference > field to rank responses. Such Preference information > is required for ILNP in order to support the use of multiple > instances of NID, L32, L64 and LP records. >=20 > G. What mnemonic is requested for the new RRTYPE (optional)? >=20 > As described in this draft, "NID", "L32", "L64", and "LP". >=20 > H. Does the requested RRTYPE make use of any existing IANA > Registry or require the creation of a new IANA > sub-registry in DNS Parameters? >=20 > Existing registry of DNS Resource Record (RR) data TYPE > values should be used. >=20 > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being > processed as an unknown RRTYPE (see [RFC3597]) ? >=20 > No. >=20 > J. Comments: > This document defines "ILNP-aware" DNS servers > or DNS resolver as a DNS server (authoritative or recursive) > that MAY include other ILNP RRTypes in the Additional > section of a DNS response that match a QNAME (if > size permits). This is to reduce the number of > DNS stub resolver follow-up DNS queries. and only applies > when the QTYPE is either NID, L32, L64, or LP. There is no > signalling mechanism for this Additional section > processing, and this is believed to be compatible > with existing non-ILNP-aware DNS servers and DNS stub > resolvers. >=20 > No changes are required for existing deployed > DNS servers or DNS resolvers. >=20 >=20 From paul.hoffman@vpnc.org Fri Jul 6 07:32:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231FC21F85E6 for ; Fri, 6 Jul 2012 07:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+tU1c2FHAdy for ; Fri, 6 Jul 2012 07:32:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9F21F85E5 for ; Fri, 6 Jul 2012 07:32:55 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q66EXArq017099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 07:33:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120706085916.AED242238832@drugs.dv.isc.org> Date: Fri, 6 Jul 2012 07:33:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1FA458DB-1E9A-40ED-99CE-1047A0C5EDB8@vpnc.org> References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <20120703141331.45D4D222DC10@drugs.dv.isc.org> <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org> <20120706085916.AED242238832@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1278) Cc: IETF DNSEXT WG Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:32:56 -0000 On Jul 6, 2012, at 1:59 AM, Mark Andrews wrote: > For a expert to be able to evaluate a RR type definition it needs > to be stable. The expert reviews a stable request, yes. > No expert can say a RR type definintion can be said > to be safe / good if it is still subject to change. Then don't ask the expert to say that. Isn't this obvious? >> - Force Internet-Drafts to keep their RRtype as TBD all the way until = >> the IESG passes the Internet-Draft to the RFC Editor >> >> - Allow WGs and document authors to request RRtype assignment earlier in = >> the process and know that there might be a change based on technical = >> review of the document >> >> Pick one. Humorously, you didn't reply to this. --Paul Hoffman From cet1@hermes.cam.ac.uk Fri Jul 6 11:56:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DDF11E809F for ; Fri, 6 Jul 2012 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shbl--x1wCUX for ; Fri, 6 Jul 2012 11:56:09 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA611E8079 for ; Fri, 6 Jul 2012 11:56:00 -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]:44788) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1SnDhR-0004su-md (Exim 4.72) for dnsext@ietf.org (return-path ); Fri, 06 Jul 2012 19:56:17 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1SnDhR-0004wJ-1c (Exim 4.67) for dnsext@ietf.org (return-path ); Fri, 06 Jul 2012 19:56:17 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 06 Jul 2012 19:56:16 +0100 Date: 06 Jul 2012 19:56:16 +0100 From: Chris Thompson To: dnsext@ietf.org Message-ID: In-Reply-To: References: <4FD62E4E.4020007@ogud.com> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:56:09 -0000 On Jul 5 2012, Donald Eastlake wrote: >Hi Dick, > >On Thu, Jul 5, 2012 at 6:06 PM, Dick Franks wrote: >> Donald, >> >> My apologies for late response. >> >> >> On 22 June 2012 19:10, Donald Eastlake wrote: >> ... >>>> [3.1 paragraph 4] >>>> and [3.2 paragraph 4] >>>> >>>> Regexes: >>>> >>>> [A-Z][A-Z0-9\-]*[A-Z0-9] >>>> >>>> (TYPE|CLASS)(0|[1-9][0-9]*) >>>> >>>> could be simplified to: >>>> >>>> [A-Z][A-Z0-9]* >>>> >>>> (TYPE|CLASS)[0-9]* >>> >>> That's not simplification, that's change. >> A simplification of the underlying production rule for RRTYPE mnemonics, >> which inevitably flows through to the regex. > >OK, it is a simplification of the RegEx, but one I don't agree with. Regardless of the hyphen question in the first regexp, I think the change to the second is probably desirable. I don't think RFC 3597 makes it totally unambiguous that unnecessary leading zeros are not allowed after TYPE or CLASS, and it is sensible to protect parsers that are sloppy in this respect. Otherwise, one could argue that TYPE65536 ought to be allowed for a new RR type mnemonic, because it clearly isn't meaningful as a generic one. This is all a bit reminiscent of the deprecation of all-digit TLDs. Ought ".000" or ".256" to be allowed because they are would not be part of the natural representation of IPv4 addresses? -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From d3e3e3@gmail.com Fri Jul 6 12:33:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27B721F855F for ; Fri, 6 Jul 2012 12:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.525 X-Spam-Level: X-Spam-Status: No, score=-103.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nU6NBZ8GSCZ for ; Fri, 6 Jul 2012 12:33:15 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC22521F854A for ; Fri, 6 Jul 2012 12:33:14 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9844855ggn.31 for ; Fri, 06 Jul 2012 12:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GW/jl0kJUxk9P4Qq7cQlViiMaLi9XrEzA5aW0hax0mo=; b=Yxz2OdsON5lB5ww0GxU1QElIh3rogJ7hpK9stpbUxFMhOatiE3Bj3UONbtssNbek9D q8tvNlPYamCO++MB+doqmhnVl5RcAvCLu34Es3uLQ7RgTqqFcd8fxmNr+U1W1fU3Q6BY rOJUj6MU3VZfVT7GvuOxS6thQuyZxJb6zk+TKDxHzM3eTqp+LlZeZ7ZvsP7yyJifuIzH 4wqONhveREpKMjRHXZ79pXGj4kvtg50ebqXONm+oUzlhoxTwtM28aQUR75x+dESArzap X7g639L8eHryhw9/GBlCpjJumlk/xuvROFNZyo1gzOKugHnPW082Nj2CmobFMIjGSoBd HQ9g== Received: by 10.50.196.201 with SMTP id io9mr3214276igc.58.1341603211545; Fri, 06 Jul 2012 12:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Fri, 6 Jul 2012 12:33:11 -0700 (PDT) In-Reply-To: References: <4FD62E4E.4020007@ogud.com> From: Donald Eastlake Date: Fri, 6 Jul 2012 15:33:11 -0400 Message-ID: To: cet1@cam.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 19:33:15 -0000 Hi Chris, On Fri, Jul 6, 2012 at 2:56 PM, Chris Thompson wrote: > On Jul 5 2012, Donald Eastlake wrote: > >> Hi Dick, >> >> On Thu, Jul 5, 2012 at 6:06 PM, Dick Franks wrote: >>> >>> Donald, >>> >>> My apologies for late response. >>> >>> >>> On 22 June 2012 19:10, Donald Eastlake wrote: >>> ... >>>>> >>>>> [3.1 paragraph 4] >>>>> and [3.2 paragraph 4] >>>>> >>>>> Regexes: >>>>> >>>>> [A-Z][A-Z0-9\-]*[A-Z0-9] >>>>> >>>>> (TYPE|CLASS)(0|[1-9][0-9]*) >>>>> >>>>> could be simplified to: >>>>> >>>>> [A-Z][A-Z0-9]* >>>>> >>>>> (TYPE|CLASS)[0-9]* >>>> >>>> >>>> That's not simplification, that's change. >>> >>> A simplification of the underlying production rule for RRTYPE mnemonics, >>> which inevitably flows through to the regex. >> >> >> OK, it is a simplification of the RegEx, but one I don't agree with. > > > Regardless of the hyphen question in the first regexp, I think the > change to the second is probably desirable. I don't think RFC 3597 > makes it totally unambiguous that unnecessary leading zeros are not > allowed after TYPE or CLASS, and it is sensible to protect parsers > that are sloppy in this respect. > > Otherwise, one could argue that TYPE65536 ought to be allowed for > a new RR type mnemonic, because it clearly isn't meaningful as a > generic one. I agree and that change is actually already in the -03 version of the draft. > This is all a bit reminiscent of the deprecation of all-digit TLDs. > Ought ".000" or ".256" to be allowed because they are would not > be part of the natural representation of IPv4 addresses? Not that relevant to our current discussion but it is my personal opinion that all-numeric TLDs should be prohibited regardless of length. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Chris Thompson University of Cambridge Computing Service, > Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 United Kingdom. From rlegene@gmail.com Sun Jul 8 17:33:19 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908921F87B8 for ; Sun, 8 Jul 2012 17:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSRTdgDnJBqJ for ; Sun, 8 Jul 2012 17:33:19 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A921F87B1 for ; Sun, 8 Jul 2012 17:33:15 -0700 (PDT) Received: by were53 with SMTP id e53so1739760wer.31 for ; Sun, 08 Jul 2012 17:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XlyyIh4cCyzXlvEHkXc/e+zgcSpuwwT2wBdIwaokASo=; b=BFOCIws/7HRbvkN9vdZNyOclIgG/puUeK1AnlJxVDPdHAYQNc/+eTcTYHSwsqnYB4t Inw7szOLBgpLO0xK9r/R3k63FcHzdPG5/+1LBd4g6VEaSIQAnr5fNDYn/pdefMVx5ZEl yj6UaExE6U18FhMUidutgT55zg9nBgX949DLUEDE2CCr0gXjgYDtix8tRyRhLh8V7cOg SEko7c2RG3VGqX4FaBbRkCT5jzxynLp3R7Vp4RrGS7wvOElo6FxJtOz8HxgexypJKLZK VQK17Vb0m+YsAmPU5rCW6oM0I/CXelW6rqgJ0rB89UaGtS3RYJPZrPJXWEzNz6J3kvMv MbsA== MIME-Version: 1.0 Received: by 10.180.97.201 with SMTP id ec9mr25078931wib.12.1341794018721; Sun, 08 Jul 2012 17:33:38 -0700 (PDT) Received: by 10.216.27.69 with HTTP; Sun, 8 Jul 2012 17:33:38 -0700 (PDT) In-Reply-To: References: <20120703021834.802.77326.idtracker@ietfa.amsl.com> Date: Sun, 8 Jul 2012 21:33:38 -0300 Message-ID: From: Robert Martin-Legene To: Donald Eastlake Content-Type: multipart/alternative; boundary=f46d04430660d9004604c45ac3f6 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 00:33:19 -0000 --f46d04430660d9004604c45ac3f6 Content-Type: text/plain; charset=ISO-8859-1 Hi Donald. Section 3.1.1 mentions dns-rrtype-applications@iana.org which, upon reading the rest of the document, seems to be wrong. Everywhere else talks of @ ietf.org. Looks good otherwise. -- Robert --f46d04430660d9004604c45ac3f6 Content-Type: text/html; charset=ISO-8859-1 Hi Donald.

Section 3.1.1 mentions dns-rrtype-applications@iana.org which, upon reading the rest of the document, seems to be wrong. Everywhere else talks of @ietf.org.

Looks good otherwise.


--
Robert

--f46d04430660d9004604c45ac3f6-- From d3e3e3@gmail.com Sun Jul 8 19:35:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932A221F8806 for ; Sun, 8 Jul 2012 19:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1bJTcU7Yt8Q for ; Sun, 8 Jul 2012 19:35:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC0ED21F8805 for ; Sun, 8 Jul 2012 19:35:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so12166127yhq.31 for ; Sun, 08 Jul 2012 19:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3ju/2CWCkugaEMr0aQEP00WOrgNAD7Us/sIujSE2vMw=; b=zJLPN4Qp8TcOkQa6dtTDQFsTJX3yYEz5ojYkPeABp6iXsgxYr9QuBl5oi/oyAozOTV iXLR+dLqN54qr8b/zzugbU3gPKCDa64Hy+tyXC9BgXgPOKYjvllhHhdY8nZ8uP1hSbSX pMb9vTBrTzgQ+v1B0oA/heZW0IO6c2CwnJTyMEXNgHHBpwFhFrkzdpileMGoBDNjZvYk mwLgzrUDZxa3tMtP9hhTCRrtBxviNL7lp2C9I79stP9Tanj0VGC2Mlh1ea+TM5FNCPBj YhZDqr4ytBG0hR4pCZuEYqLvUp/yUCw50jCWvf3MFX2yih/eiuRudEMLNcKAjpbjQGQa 98Uw== Received: by 10.43.106.1 with SMTP id ds1mr19736475icc.24.1341801322987; Sun, 08 Jul 2012 19:35:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Sun, 8 Jul 2012 19:35:02 -0700 (PDT) In-Reply-To: References: <20120703021834.802.77326.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 8 Jul 2012 22:35:02 -0400 Message-ID: To: Robert Martin-Legene Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:35:01 -0000 Ahh, sorry for not figuring out what you meant. Looking back to the correspondence with IANA and other evidence, it does seem to be @ietf.org. I'll fix the draft. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Jul 8, 2012 at 8:33 PM, Robert Martin-Legene wrote: > Hi Donald. > > Section 3.1.1 mentions dns-rrtype-applications@iana.org which, upon reading > the rest of the document, seems to be wrong. Everywhere else talks of > @ietf.org. > > Looks good otherwise. > > > -- > Robert From weiler@watson.org Tue Jul 10 06:20:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600EE21F86CA for ; Tue, 10 Jul 2012 06:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbjRby6JpbyY for ; Tue, 10 Jul 2012 06:20:13 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF421F86C6 for ; Tue, 10 Jul 2012 06:20:13 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q6ADKeNC010600 for ; Tue, 10 Jul 2012 09:20:40 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q6ADKeee010596 for ; Tue, 10 Jul 2012 09:20:40 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 10 Jul 2012 09:20:40 -0400 (EDT) From: Samuel Weiler To: dnsext@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 10 Jul 2012 09:20:40 -0400 (EDT) Subject: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:20:14 -0000 I've been churning through the IESG telechat comments and single discuss on draft-ietf-dnsext-dnssec-bis-updates. I have two questions for the WG, and I want to report on several textual changes that I plan to adopt, inspired by the IESG's comments. Q1: (from Stephen Farrell) > During the "no answer" mega-discussion on the DANE list, [1] I > seem to recall this comment was made more than once: "you're > seeing all this because you're maybe the first new > application that really needs DNSSEC," or words to that > effect. Should any of that discussion be reflected in this > document? (I assume its not already there for timing reasons > if nothing else.) > > [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html Q2: There's been another call to explain why section 3.1 says a validator MUST implement a BAD cache. If nothing better comes up, I plan to just cite http://www.potaroo.net/ispcol/2010-02/rollover.html Is there anything better? Or is there a short summary we can just copy into this doc? And the changes I've made in my working copy of the draft. > -- 2.1 -- > signal that a zone MAY be using NSEC3, rather than NSEC. > > This MAY and the one in the following paragraph are misused: they should not > be 2119 terms. Describing what a zone "may be using" is simply a descriptive > phrase, not anything normative. Actually, I would say "might be using". Done. > 1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does the > outside world know DNSSECbis isn't DNSSEC? This is an artifact of the ages. We started this doc just after 4034 et. al. were published, and the WG still referred to them as DNSSECbis. Given today's usage, we should probably make the change. > 2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple > of times I thought the RFC references needed to be included in [] so it's > probably better to just do it everywhere. You also need to add [RFC2308] as > a reference. Added the 2308 reference. I'll leave the rest to the rfc editor. > 3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either > r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the > Internet Standards track. Or something like that. Done. > 5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} > be" with "are"? If the WG considers them part of the core, then aren't they? > It also avoids the whole question about whether it ought to be SHOULD (not > that I'm asking to change that). Sure. I used "are now" and "is now". > 9) s5.11: could you just strike "note that" Sure. How about "This requirement applies to servers, not validators."? Lastly, there is one open Discuss on the document, inspired by a GenART review. Andrew Sullivan replied to the GenART review on the IETF list. I'm waiting for a response from Russ Housley, and I'm hoping we can resolve that without more textual changes. Feel free to comment on that thread separately. -- Sam From paul.hoffman@vpnc.org Tue Jul 10 07:50:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65A921F86E3 for ; Tue, 10 Jul 2012 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TseJXhYzAhXo for ; Tue, 10 Jul 2012 07:50:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15621F86DC for ; Tue, 10 Jul 2012 07:50:24 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6AEooAn014037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 07:50:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Jul 2012 07:50:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Samuel Weiler X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:50:29 -0000 On Jul 10, 2012, at 6:20 AM, Samuel Weiler wrote: > I've been churning through the IESG telechat comments and single = discuss on draft-ietf-dnsext-dnssec-bis-updates. >=20 > I have two questions for the WG, and I want to report on several = textual changes that I plan to adopt, inspired by the IESG's comments. >=20 >=20 > Q1: (from Stephen Farrell) >=20 >> During the "no answer" mega-discussion on the DANE list, [1] I >> seem to recall this comment was made more than once: "you're >> seeing all this because you're maybe the first new >> application that really needs DNSSEC," or words to that >> effect. Should any of that discussion be reflected in this >> document? (I assume its not already there for timing reasons >> if nothing else.) >>=20 >> [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html It would be helpful to DANE and future protocols if "no answer" was = discussed more fully. The amount of differing opinions about the four = states *even among DNSSEC-knowledgeable people* in that thread and = others was significant. The fact that "bogus" is defined differently in = different DNSSEC documents didn't help us come to conclusion, either. > Q2: There's been another call to explain why section 3.1 says a = validator MUST implement a BAD cache. If nothing better comes up, I = plan to just cite http://www.potaroo.net/ispcol/2010-02/rollover.html Is = there anything better? Or is there a short summary we can just copy = into this doc? Citing that article works, but a short summary would be better. --Paul Hoffman From warren@kumari.net Tue Jul 10 13:27:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845421F86B7 for ; Tue, 10 Jul 2012 13:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFuc3n6IIRsF for ; Tue, 10 Jul 2012 13:27:48 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E778021F86AA for ; Tue, 10 Jul 2012 13:27:47 -0700 (PDT) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 87B921B402E4; Tue, 10 Jul 2012 16:28:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 10 Jul 2012 16:28:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:27:49 -0000 On Jul 10, 2012, at 10:50 AM, Paul Hoffman wrote: > On Jul 10, 2012, at 6:20 AM, Samuel Weiler wrote: >=20 >> I've been churning through the IESG telechat comments and single = discuss on draft-ietf-dnsext-dnssec-bis-updates. >>=20 >> I have two questions for the WG, and I want to report on several = textual changes that I plan to adopt, inspired by the IESG's comments. >>=20 >>=20 >> Q1: (from Stephen Farrell) >>=20 >>> During the "no answer" mega-discussion on the DANE list, [1] I >>> seem to recall this comment was made more than once: "you're >>> seeing all this because you're maybe the first new >>> application that really needs DNSSEC," or words to that >>> effect. Should any of that discussion be reflected in this >>> document? (I assume its not already there for timing reasons >>> if nothing else.) >>>=20 >>> [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html >=20 > It would be helpful to DANE and future protocols if "no answer" was = discussed more fully. The amount of differing opinions about the four = states *even among DNSSEC-knowledgeable people* s/even/especially/ A number of DANE folk (myself included) had an instinctual understanding = of various results, including "no answer" and "bogus" -- unfortunately = we all seemed to have differnt understandings... > in that thread and others was significant. The fact that "bogus" is = defined differently in different DNSSEC documents didn't help us come to = conclusion, either. Yup! W >=20 >> Q2: There's been another call to explain why section 3.1 says a = validator MUST implement a BAD cache. If nothing better comes up, I = plan to just cite http://www.potaroo.net/ispcol/2010-02/rollover.html Is = there anything better? Or is there a short summary we can just copy = into this doc? >=20 > Citing that article works, but a short summary would be better. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 Credo quia absurdum est. From patrik@frobbit.se Wed Jul 11 00:06:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDB11E80F4 for ; Wed, 11 Jul 2012 00:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTlJkCKlMMZJ for ; Wed, 11 Jul 2012 00:06:24 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3475011E8098 for ; Wed, 11 Jul 2012 00:06:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 588C9142D12CC; Wed, 11 Jul 2012 09:06:52 +0200 (CEST) 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 goXghhSh9bMy; Wed, 11 Jul 2012 09:06:52 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 27CF2142D12C2; Wed, 11 Jul 2012 09:06:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 11 Jul 2012 09:06:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 07:06:25 -0000 On 10 jul 2012, at 16:50, Paul Hoffman wrote: > The amount of differing opinions about the four states *even among = DNSSEC-knowledgeable people* in that thread and others was significant. The big difference is between people that do think it is a good thing = that people in X.509 world themselves can "click" on "continue anyways" = on a validation failure. I think personally it is *feature* that with = DNSSEC a validator by default do not return anything if validation fails = for some reasons, and the end user can not do anything at all about it = (part from running its own resolver etc etc). But I do understand other people do have other views. Because of this, for me, a no-response in DANE is the same as failed = validation, and such a failure that the end user/application should not = continue. At all. No "continue anyway" etc. Giving the ability "to continue" opens the door for denial of service = attacks as a way to circumvent DANE security. So to me there are three states only. - No DANE in use - DANE in use, validation succeeds - All other cases Patrik From ajs@anvilwalrusden.com Wed Jul 11 04:59:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FFE21F8625 for ; Wed, 11 Jul 2012 04:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUYGDaKHlnVG for ; Wed, 11 Jul 2012 04:59:13 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91621F8622 for ; Wed, 11 Jul 2012 04:59:13 -0700 (PDT) Received: from mail.yitter.info (bas1-malton22-1167905092.dsl.bell.ca [69.156.209.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 43C308A031 for ; Wed, 11 Jul 2012 11:59:43 +0000 (UTC) Date: Wed, 11 Jul 2012 07:59:43 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120711115942.GB82178@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:59:14 -0000 No hat. On Tue, Jul 10, 2012 at 07:50:51AM -0700, Paul Hoffman wrote: > It would be helpful to DANE and future protocols if "no answer" was > discussed more fully. The amount of differing opinions about the > four states *even among DNSSEC-knowledgeable people* in that thread > and others was significant. The fact that "bogus" is defined > differently in different DNSSEC documents didn't help us come to > conclusion, either. Although I agree with this, I thought the difference between the docs was explained by the different perspectives the documents were working from? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Wed Jul 11 07:41:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF92A21F86E2 for ; Wed, 11 Jul 2012 07:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCqN0FGFA3d6 for ; Wed, 11 Jul 2012 07:41:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6F721F86E0 for ; Wed, 11 Jul 2012 07:41:34 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6BEftCt038001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jul 2012 07:41:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Wed, 11 Jul 2012 07:41:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B8B6E62-3903-4B26-821C-DFA55FA6D4F3@vpnc.org> References: To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:41:34 -0000 On Jul 11, 2012, at 12:06 AM, Patrik F=E4ltstr=F6m wrote: >=20 > On 10 jul 2012, at 16:50, Paul Hoffman wrote: >=20 >> The amount of differing opinions about the four states *even among = DNSSEC-knowledgeable people* in that thread and others was significant. >=20 > The big difference is between people that do think it is a good thing = that people in X.509 world themselves can "click" on "continue anyways" = on a validation failure. That is *not* where the difference of opinions about DNSSEC were. The = differences were about what specific events constitute bogus versus = indeterminate or insecure. There were good reasons for the WG to = differentiate between bogus and indeterminate/insecure, but the DNSSEC = documents had places of unclarity, including two different definitions = of "bogus". > I think personally it is *feature* that with DNSSEC a validator by = default do not return anything if validation fails for some reasons, and = the end user can not do anything at all about it (part from running its = own resolver etc etc). >=20 > But I do understand other people do have other views. Exactly. The "other views" from different people who the community = thinks understand DNSSEC made it hard for us to know what to put in our = document. Thus, the request for clarity in *this* document. > Because of this, for me, a no-response in DANE is the same as failed = validation, and such a failure that the end user/application should not = continue. At all. No "continue anyway" etc. This view ignores the fact that PKIX has its own protections to which = DANE is adding value. It is fine if this WG wants to say in = dnssec-bis-updates that other protocols that want to add value with = DNSSEC should fail to less than the protocol if DNSSEC does not return = "secure", and it is fine if this WG wants to say that "we aren't going = to specify what other protocols will do", but the current DNSSEC = documents do neither. > Giving the ability "to continue" opens the door for denial of service = attacks as a way to circumvent DANE security. >=20 > So to me there are three states only. >=20 > - No DANE in use > - DANE in use, validation succeeds > - All other cases If you want to change DANE, please so do in the DANE WG. The thread here = is about making the DNSSEC document clearer for other WGs who will want = to use DNSSEC. If the DNSSEC spec had been clearer on what bogus means = and what the expectation of the IETF is for why there is a difference = between insecure and indeterminate, the DANE WG discussion would have = gone *much* better. --Paul Hoffman From internet-drafts@ietf.org Fri Jul 13 15:21:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0C11E8116; Fri, 13 Jul 2012 15:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XWOchH-Znug; Fri, 13 Jul 2012 15:21:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8111E80EC; Fri, 13 Jul 2012 15:21:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120713222124.30361.25897.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 15:21:24 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-19.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSEC Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-19.txt Pages : 21 Date : 2012-07-13 Abstract: This document is a collection of technical clarifications to the DNSSEC document set. It is meant to serve as a resource to implementors as well as a repository of DNSSEC errata. This document updates the core DNSSEC documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSEC specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-bis-updates-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From weiler@watson.org Sat Jul 14 04:04:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC321F8639 for ; Sat, 14 Jul 2012 04:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alvfDBIbiXu0 for ; Sat, 14 Jul 2012 04:04:48 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9321F8637 for ; Sat, 14 Jul 2012 04:04:48 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q6EB5M3A005123; Sat, 14 Jul 2012 07:05:22 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q6EB5MMH005119; Sat, 14 Jul 2012 07:05:22 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 14 Jul 2012 07:05:22 -0400 (EDT) From: Samuel Weiler To: Scott Rose In-Reply-To: <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> Message-ID: References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com> <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 14 Jul 2012 07:05:23 -0400 (EDT) Cc: DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:04:49 -0000 On Mon, 26 Mar 2012, Scott Rose wrote: > This version addresses Sam Weiler's comments on the -00 version and > adds the ECDSA algorithms. If the group thinks any of the assigned > implementation status for entries should be changed - please state > so. Personally, I'm thinking ECDSA might be moved to > "Recommended..." since there are some advantages, but willing to > leave it as is. Thank you for addressing all of my comments. I appreciate the attention to detail. No opinion re: ECDSA. -- Sam From weiler@watson.org Sat Jul 14 04:17:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68C421F8736; Sat, 14 Jul 2012 04:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNWiQIFOoMio; Sat, 14 Jul 2012 04:17:39 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42D21F8735; Sat, 14 Jul 2012 04:17:38 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q6EBIHXH009866; Sat, 14 Jul 2012 07:18:17 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q6EBIHPj009863; Sat, 14 Jul 2012 07:18:17 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 14 Jul 2012 07:18:17 -0400 (EDT) From: Samuel Weiler To: ietf@ietf.org In-Reply-To: <20120627135256.11457.74759.idtracker@ietfa.amsl.com> Message-ID: References: <20120627135256.11457.74759.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 14 Jul 2012 07:18:17 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:17:39 -0000 General comment: no objection. The table in section 2.2 is odd: in addition to the three entries being updated, it lists some BUT NOT ALL of the other assignments already made. I suspect that's a historical artifact. My suggestion: since the intro text in that section says "The list of .. registry entry changes is below", remove all entries that aren't changing. That will make the reader's job easier. -- Sam Weiler From internet-drafts@ietf.org Sun Jul 15 15:53:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BC411E808F; Sun, 15 Jul 2012 15:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtTJmVvoPoq0; Sun, 15 Jul 2012 15:53:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7AD21F841E; Sun, 15 Jul 2012 15:53:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120715225319.24623.25843.idtracker@ietfa.amsl.com> Date: Sun, 15 Jul 2012 15:53:19 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 22:53:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : Donald E. Eastlake Filename : draft-ietf-dnsext-rfc6195bis-04.txt Pages : 22 Date : 2012-07-15 Abstract: This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-rfc6195bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Sun Jul 15 15:58:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C554511E8088 for ; Sun, 15 Jul 2012 15:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN+cmFPDR1in for ; Sun, 15 Jul 2012 15:58:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6411E8085 for ; Sun, 15 Jul 2012 15:58:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9516993obb.31 for ; Sun, 15 Jul 2012 15:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DSddVGGYcQUCXHgPET2J3CmeQ7X3hBmFYA0lIk+UBvI=; b=Spb/rTCeKuiIjcAxJC/7y0zRiF/JCbiCkJ+3R4/RATG4q+O/sSXXHgpH1Yqp5Vc1jl X2NjMa/BEX+q6BfY8upFFbThD0JoGlSiBThQIt7XZ91zmdqkvP3LFMgDGBL9GtxMNopf LIB+RqUTS7z07LeL1i1BwsY/lCaFhLRdmZ80HZFUY8uFiSFi/78JPG/XEWEL0TpmO7j5 pDuh8YkeCjfz47jhM8B6DgVNzR+8AHm+u5rtH07etJAM53eG6E2cqHldEcfEIkle3ruu F8IUWXsURCNeAB42GwhMU3U9k/GUHhfqGUOvPdndwmNfSQ0dCJos9BWexpqVUHN37Z3q VX1w== Received: by 10.50.34.200 with SMTP id b8mr3942029igj.50.1342393162816; Sun, 15 Jul 2012 15:59:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Sun, 15 Jul 2012 15:59:02 -0700 (PDT) In-Reply-To: <20120715225319.24623.79754.idtracker@ietfa.amsl.com> References: <20120715225319.24623.79754.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 15 Jul 2012 18:59:02 -0400 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [dnsext] Fwd: New Version Notification for draft-ietf-dnsext-rfc6195bis-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 22:58:40 -0000 Hi, Changes from the previous version are quite small as you can see at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dnsext-rfc6195bis-04.txt I believe this incorporates all comment resolutions that have been agreed to on the list. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com ---------- Forwarded message ---------- From: Date: Sun, Jul 15, 2012 at 6:53 PM Subject: New Version Notification for draft-ietf-dnsext-rfc6195bis-04.txt To: d3e3e3@gmail.com A new version of I-D, draft-ietf-dnsext-rfc6195bis-04.txt has been successfully submitted by Donald E. Eastlake and posted to the IETF repository. Filename: draft-ietf-dnsext-rfc6195bis Revision: 04 Title: Domain Name System (DNS) IANA Considerations Creation date: 2012-07-15 WG ID: dnsext Number of pages: 22 URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-04.txt Status: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis Htmlized: http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-04 Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsext-rfc6195bis-04 Abstract: This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The IETF Secretariat From bertietf@bwijnen.net Sun Jul 15 00:03:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8221F84EC; Sun, 15 Jul 2012 00:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPLzv8ntUBcV; Sun, 15 Jul 2012 00:03:24 -0700 (PDT) Received: from relay59.tele2.vuurwerk.nl (relay59.tele2.vuurwerk.nl [62.250.3.59]) by ietfa.amsl.com (Postfix) with ESMTP id B39AE21F84EB; Sun, 15 Jul 2012 00:03:22 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1SqIs5-00063H-VP; Sun, 15 Jul 2012 09:04:02 +0200 Message-ID: <7981A832108446BA9EEC7C4742B87BFF@BertLaptop> From: "Bert Wijnen \(IETF\)" To: Date: Sun, 15 Jul 2012 09:03:56 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 X-Mailman-Approved-At: Sun, 15 Jul 2012 16:36:31 -0700 Cc: ops-dir@ietf.org, ops-ads@ietf.org, dnsext@ietf.org Subject: [dnsext] Operations Directorate Review of draft-ietf-dnsext-dnssec-registry-update-03 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 07:03:25 -0000 Sorry for being a tidbit late (My excuse is that I was on vacation and only saw this request this morning). I believe that this (short) document is well written and ready for publication. This is a set of updates to the DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry. As far as I can tell, that does not have any operatioal or network management impact in the Inetrnet. Bert Wijnen ----- Original Message ----- From: "Tina TSOU" To: Cc: ; Sent: Saturday, June 30, 2012 5:41 AM Subject: Request for Operations Directorate Review of draft-ietf-dnsext-dnssec-registry-update-03 by 2012-07-11 Hello, As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact. IETF Last Call: The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ballot/ Please provide comments and review to the Ops-dir mailing list (ops-dir@ietf.org) by 2012-07-11, and include the authors of the draft as well. A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review. Would you add the review requests and update the status by yourself at our wiki page? http://trac.tools.ietf.org/area/ops/trac/wiki/Reviews Thank you, Tina From scottr.nist@gmail.com Mon Jul 16 07:25:27 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03D321F879D; Mon, 16 Jul 2012 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf24VVimkVsP; Mon, 16 Jul 2012 07:25:26 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EB7D421F8790; Mon, 16 Jul 2012 07:25:25 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Jul 2012 10:26:04 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Mon, 16 Jul 2012 10:26:06 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q6GEQ5A3010058; Mon, 16 Jul 2012 10:26:06 -0400 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_815F6DFD-0B17-462C-9D85-50F01FE1BAD1" From: Scott Rose In-Reply-To: Date: Mon, 16 Jul 2012 10:26:05 -0400 Message-ID: References: <20120627135256.11457.74759.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1278) Cc: ietf@ietf.org Subject: Re: [dnsext] Last Call: (DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:25:27 -0000 --Apple-Mail=_815F6DFD-0B17-462C-9D85-50F01FE1BAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Thanks for the review. =20 The table in section 2.2 in the -03 draft only has the entries that need = to be updated. Besides the 3 entries that are now Reserved, but the = references for some other entries have been fixed. I removed the = correct, unchanged entries for readability (the mnemonics for some of = the entires skewed the table and made it difficult to read). Scott=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Jul 14, 2012, at 7:18 AM, Samuel Weiler wrote: > General comment: no objection. >=20 > The table in section 2.2 is odd: in addition to the three entries = being updated, it lists some BUT NOT ALL of the other assignments = already made. I suspect that's a historical artifact. My suggestion: = since the intro text in that section says "The list of .. registry entry = changes is below", remove all entries that aren't changing. That will = make the reader's job easier. >=20 > -- Sam Weiler >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_815F6DFD-0B17-462C-9D85-50F01FE1BAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
scott.rose@nist.gov
+1 = 301-975-8439
Google Voice: +1 = 571-249-3671
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Jul 14, 2012, at 7:18 AM, Samuel Weiler wrote:

General= comment: no objection.

The table in section 2.2 is odd: in = addition to the three entries being updated, it lists some BUT NOT ALL = of the other assignments already made.  I suspect that's a = historical artifact.  My suggestion: since the intro text in that = section says "The list of .. registry entry changes is below", remove = all entries that aren't changing. That will make the reader's job = easier.

-- Sam = Weiler

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

= --Apple-Mail=_815F6DFD-0B17-462C-9D85-50F01FE1BAD1-- From patrik@frobbit.se Tue Jul 17 05:59:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C263F21F866C for ; Tue, 17 Jul 2012 05:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFBBnrIDHkBD for ; Tue, 17 Jul 2012 05:59:21 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2C88A21F8665 for ; Tue, 17 Jul 2012 05:59:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 7CF6F14354299 for ; Tue, 17 Jul 2012 15:00:07 +0200 (CEST) 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 ovFa8BdnIAZa for ; Tue, 17 Jul 2012 15:00:02 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id B48F814354284 for ; Tue, 17 Jul 2012 15:00:02 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2012 15:00:02 +0200 Message-Id: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 12:59:21 -0000 All, As this was announced on June 14, 2012, and Scott Rose immediately = followed up with an announcement = (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and = there have been exactly zero comments I am a bit shy of declaring = victory. Can I get please at least three people that have seen this version, read = it, and support it moving forward (part from myself and the authors of = the document? Patrik From warren@kumari.net Tue Jul 17 08:54:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974621F8668 for ; Tue, 17 Jul 2012 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65s-BxC8zwHE for ; Tue, 17 Jul 2012 08:54:06 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB8C21F8667 for ; Tue, 17 Jul 2012 08:54:05 -0700 (PDT) Received: from [192.168.1.101] (66-87-87-245.pools.spcsdns.net [66.87.87.245]) by vimes.kumari.net (Postfix) with ESMTPSA id 2E1531B40115; Tue, 17 Jul 2012 11:54:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> Date: Tue, 17 Jul 2012 11:55:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 15:54:11 -0000 On Jul 17, 2012, at 9:00 AM, Patrik F=E4ltstr=F6m wrote: > All, >=20 > As this was announced on June 14, 2012, and Scott Rose immediately = followed up with an announcement = (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and = there have been exactly zero comments I am a bit shy of declaring = victory. >=20 > Can I get please at least three people that have seen this version, = read it, and support it moving forward (part from myself and the authors = of the document? I have (finally!) reread the document (again!) and to be honest am = getting bored with it -- I believe it is fully cooked and should be = taken out of the oven and published before it gets burnt=85. Warren "Stretching Analogies to Failure" Kumari. >=20 > Patrik >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 -- The plural of anecdote is not evidence. -- Bill Lockyer, California Attorney General From paul.hoffman@vpnc.org Tue Jul 17 09:23:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC0C21F85B4 for ; Tue, 17 Jul 2012 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgtR9qFL2C8z for ; Tue, 17 Jul 2012 09:23:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2190C21F8551 for ; Tue, 17 Jul 2012 09:23:15 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6HFbuFX077517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2012 08:37:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> Date: Tue, 17 Jul 2012 09:23:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:23:16 -0000 On Jul 17, 2012, at 6:00 AM, Patrik F=E4ltstr=F6m wrote: > As this was announced on June 14, 2012, and Scott Rose immediately = followed up with an announcement = (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and = there have been exactly zero comments I am a bit shy of declaring = victory. >=20 > Can I get please at least three people that have seen this version, = read it, and support it moving forward (part from myself and the authors = of the document? I have read the document and think it may be ready for IETF review, but = it also might not. Section 3 still says: The validating end-system resolver sets the value(s) in the order of preference, with the most preferred algorithm(s) first as described in section 2. It does not say how a resolver choses the order of preference, probably = because they have no frigging idea how to measure that. How can one = express a preference between RSA and ECDSA, for example, without knowing = the RSA key length? Worse, how can you even have a preference when what = you really have is a list of algorithms that you fully accept and a list = that you fully reject? My preference remains the same: get rid of this ordering, stop = pretending that people who run resolvers care about this as much as = security geeks do, and stop suggesting to people that they should care = about something they do not understand. But if the WG wants to leave = this in, no significant harm will be done. --Paul Hoffman= From steve@shinkuro.com Tue Jul 17 09:59:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4263C21F869C for ; Tue, 17 Jul 2012 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMZhFFIGOke8 for ; Tue, 17 Jul 2012 09:59:46 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D721F869A for ; Tue, 17 Jul 2012 09:59:46 -0700 (PDT) Received: from [70.88.139.89] (account steve@shinkuro.com HELO [192.168.168.156]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20696731; Tue, 17 Jul 2012 17:00:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Steve Crocker In-Reply-To: <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> Date: Tue, 17 Jul 2012 13:00:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:59:47 -0000 Paul, There is a subtle point that may be helpful to recall. The primary = purpose of advertisement of which algorithms are understood by the = resolver is to provide a measure of the adoption of new algorithms. In = the broad, slow cycle of introduction of new algorithms and the presumed = phasing out of old algorithms, operators on the signing side of the = equation will be choosing when to sign with a new algorithm and when to = stop signing with an old algorithm. They can sign with a new algorithm = whenever they feel ready to do so, but they cannot rationally stop = signing with the old algorithm until they have evidence that essentially = all of the resolvers understand the new algorithm. Thus, as I said, the = primary purpose of this protocol extension is to provide measurable = assessment of the uptake of a new algorithm. =46rom this perspective, = the order of the algorithms within the resolver's advertisement is = irrelevant. Subordinate to this primary purpose is the potential for also = advertising a preference. Whether the responding system pays attention = to the order is up to the responding system. Also, as you suggest, the = querying system may or may not have a real preference. I don't think we = have enough information to say one way or the other, and the perfect is = the enemy of the good. Let's move this forward and revisit your concern = when there is some implementation and deployment experience to examine. = I hope is that this is the worst issue we will have to deal with. Steve On Jul 17, 2012, at 12:23 PM, Paul Hoffman wrote: > On Jul 17, 2012, at 6:00 AM, Patrik F=E4ltstr=F6m wrote: >=20 >> As this was announced on June 14, 2012, and Scott Rose immediately = followed up with an announcement = (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and = there have been exactly zero comments I am a bit shy of declaring = victory. >>=20 >> Can I get please at least three people that have seen this version, = read it, and support it moving forward (part from myself and the authors = of the document? >=20 > I have read the document and think it may be ready for IETF review, = but it also might not. Section 3 still says: > The > validating end-system resolver sets the value(s) in the order of > preference, with the most preferred algorithm(s) first as described > in section 2. > It does not say how a resolver choses the order of preference, = probably because they have no frigging idea how to measure that. How can = one express a preference between RSA and ECDSA, for example, without = knowing the RSA key length? Worse, how can you even have a preference = when what you really have is a list of algorithms that you fully accept = and a list that you fully reject? >=20 > My preference remains the same: get rid of this ordering, stop = pretending that people who run resolvers care about this as much as = security geeks do, and stop suggesting to people that they should care = about something they do not understand. But if the WG wants to leave = this in, no significant harm will be done. >=20 > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From paul.hoffman@vpnc.org Tue Jul 17 10:10:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3571C21F86BB for ; Tue, 17 Jul 2012 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6oB+qfWp1ip for ; Tue, 17 Jul 2012 10:10:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7221F86A7 for ; Tue, 17 Jul 2012 10:10:20 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6HGP4g9084057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2012 09:25:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> Date: Tue, 17 Jul 2012 10:11:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> To: Steve Crocker X-Mailer: Apple Mail (2.1278) Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:10:21 -0000 On Jul 17, 2012, at 10:00 AM, Steve Crocker wrote: > There is a subtle point that may be helpful to recall. The primary = purpose of advertisement of which algorithms are understood by the = resolver is to provide a measure of the adoption of new algorithms. In = the broad, slow cycle of introduction of new algorithms and the presumed = phasing out of old algorithms, operators on the signing side of the = equation will be choosing when to sign with a new algorithm and when to = stop signing with an old algorithm. They can sign with a new algorithm = whenever they feel ready to do so, but they cannot rationally stop = signing with the old algorithm until they have evidence that essentially = all of the resolvers understand the new algorithm. =20 Fully agree with all that. > Thus, as I said, the primary purpose of this protocol extension is to = provide measurable assessment of the uptake of a new algorithm. =46rom = this perspective, the order of the algorithms within the resolver's = advertisement is irrelevant. And that too, of course. > Subordinate to this primary purpose is the potential for also = advertising a preference. Whether the responding system pays attention = to the order is up to the responding system. Also, as you suggest, the = querying system may or may not have a real preference. =20 Nowhere in this document or any other DNSSEC RFC do we give any advice = on why a resolver should have a preference. And that's a good thing. > I don't think we have enough information to say one way or the other, We disagree, strongly. Until you can show that more than a small = fraction of the users of this will have a preference, saying that all of = them need to have a preference in order to express it in a list adds a = layer of complexity that you cannot show has any value. > and the perfect is the enemy of the good. =20 Thats a convenient way of saying "I don't know, but I liked this feature = before, so let's leave it in". Some of us prefer not to add superfluous = features and would use different trite saying to back our opinions. > Let's move this forward and revisit your concern when there is some = implementation and deployment experience to examine. =20 Errr, how? Under what criteria could that evaluation be made? I propose = that there are none possible. > I hope is that this is the worst issue we will have to deal with. Fully agree. --Paul Hoffman From rwfranks@gmail.com Tue Jul 17 11:38:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8455E21F8483 for ; Tue, 17 Jul 2012 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ePq3WLcDDZ2 for ; Tue, 17 Jul 2012 11:38:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE621F8480 for ; Tue, 17 Jul 2012 11:38:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so571464vbb.31 for ; Tue, 17 Jul 2012 11:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=F85IcvOMz8FAjpGK80AgIaUUOqC8Qv0EEl7RlLx/Zuc=; b=bDOqtQuyL/wVweHEAZM3kPn+HSEierjaP+Z2zr/Rh9wFmMlN/972dJSUzrw3Qp/8zM E5K6893Nzie3+ZFU6pcqw+tnf5C3YpbSPMBk6/F8RQpV1L4pmt3QxCxGLc9Ra2EmSVGV Awv1Ee0zSTY8NAWSrXbexRQi8GE5FT/D3rHdhKD3q8cWPCzVWHJVkaYh8LxU8hR5BOzC sHYaT3NHxAgGTsz4ElTGf+j72XU5MkF9qmYx1x6WHk3wlKs5CXCGMEGyXdxY35Ws6A4f OgqX53jgeu4k3UytByRPKuuEdMNMaLRAr0fe8bxez7KracmVp0zpIzFXVZp7qPVLehOv Ftkw== Received: by 10.52.88.170 with SMTP id bh10mr1470870vdb.11.1342550334344; Tue, 17 Jul 2012 11:38:54 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.52.157.162 with HTTP; Tue, 17 Jul 2012 11:38:34 -0700 (PDT) In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> From: Dick Franks Date: Tue, 17 Jul 2012 19:38:34 +0100 X-Google-Sender-Auth: o-cYY3NPDYycBo3R16h1JLQ7Ja8 Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:38:07 -0000 Patrik, Read version 07, and support it moving forward. Dick -- On 17 July 2012 14:00, Patrik F=C3=A4ltstr=C3=B6m wrote= : > All, > > As this was announced on June 14, 2012, and Scott Rose immediately follow= ed up with an announcement (http://www.ietf.org/mail-archive/web/dnsext/cur= rent/msg12514.html) and there have been exactly zero comments I am a bit sh= y of declaring victory. > > Can I get please at least three people that have seen this version, read = it, and support it moving forward (part from myself and the authors of the = document? > > Patrik > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From patrik@frobbit.se Tue Jul 17 11:53:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5C621F867C for ; Tue, 17 Jul 2012 11:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtCvlDFFB6qC for ; Tue, 17 Jul 2012 11:53:52 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC121F85A2 for ; Tue, 17 Jul 2012 11:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6C6D81435A6D9; Tue, 17 Jul 2012 20:54:39 +0200 (CEST) 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 JCym7iQCRyFw; Tue, 17 Jul 2012 20:54:39 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3C6851435A6CE; Tue, 17 Jul 2012 20:54:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 17 Jul 2012 20:54:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:53:58 -0000 On 17 jul 2012, at 19:11, Paul Hoffman wrote: >> I don't think we have enough information to say one way or the other, >=20 > We disagree, strongly. Until you can show that more than a small = fraction of the users of this will have a preference, saying that all of = them need to have a preference in order to express it in a list adds a = layer of complexity that you cannot show has any value. >=20 >> and the perfect is the enemy of the good. =20 >=20 > Thats a convenient way of saying "I don't know, but I liked this = feature before, so let's leave it in". Some of us prefer not to add = superfluous features and would use different trite saying to back our = opinions. Paul, I understand your issue and as one person that was part of the = design of NAPTR, user of it, confused user, I completely understand the = headache users might get that you talk about. But, while I might have = headache over the weight and preference in for example NAPTR, I know = people that do use it. So, let me ask you: Is this existence of this parameter for you a blocking factor for this = document? I do not mind if you expand a bit because I must as shepherd of this = document understand whether what you feel is something that still is in = the rough part of rough consensus, and if so that your view should be = paused until there is IETF last call and your input goes to IESG. I can understand if you see these kind of parameters in DNS "go away", = but so far we have sort of used them in many RR Types, and maybe what = you ask for is a generic change in how we design new RR Types. But the = question is whether *THIS* document should be where we take that step on = "generic design decisions". Patrik From paul.hoffman@vpnc.org Tue Jul 17 12:05:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6E21F8638 for ; Tue, 17 Jul 2012 12:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf3T5N3ss+n5 for ; Tue, 17 Jul 2012 12:05:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8024521F8624 for ; Tue, 17 Jul 2012 12:05:45 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6HIKRqF001798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2012 11:20:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Tue, 17 Jul 2012 12:06:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3604D7DA-3A1F-475F-8EB1-1787BF8A3023@vpnc.org> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:05:46 -0000 On Jul 17, 2012, at 11:54 AM, Patrik F=E4ltstr=F6m wrote: > Is this existence of this parameter for you a blocking factor for this = document? I thought I was clear in my earlier message: no, not blocking. I bring = it up now because it is a useless addition that is trivial to remove. > I do not mind if you expand a bit because I must as shepherd of this = document understand whether what you feel is something that still is in = the rough part of rough consensus, and if so that your view should be = paused until there is IETF last call and your input goes to IESG. I say "useless" because, unlike NAPTR, the ordering of the lists is = optional. Because of this, the optionality of the preference ordering = makes the ordering useless. That is, if I say I know "SHA1, SHA256" you = don't know if I prefer SHA1 (because it's shorter, and I don't care = about anything above 60 bits of strength) or whether I have no = preference and listed them in numeric order or whether that order was = set by my software. That is, you cannot determine if my order is = surprising or uninteresting. This invalidates any value to the ordering. If the WG leaves in the ordering, I believe that we need to add = "however, interpreting the order in answers will lead to wrong = conclusions". If I'm wrong and someone can show how a recipient can tell = the difference between answers that were ordered on purpose and those = that were not, that's great: we can add it to the draft. > I can understand if you see these kind of parameters in DNS "go away", = but so far we have sort of used them in many RR Types, and maybe what = you ask for is a generic change in how we design new RR Types. But the = question is whether *THIS* document should be where we take that step on = "generic design decisions". I do *not* want the parameters to go away: I said that I support the = publication of this document. All I am saying is that the optional = ordering is useless and will cause problems for validators ("where do I = read why I should have a preference") and zones who make false = assumptions on the order seen. --Paul Hoffman From patrik@frobbit.se Tue Jul 17 12:11:12 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F204221F8621 for ; Tue, 17 Jul 2012 12:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br2kCCQ+1FxW for ; Tue, 17 Jul 2012 12:11:11 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4126521F8703 for ; Tue, 17 Jul 2012 12:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 783A71435A9C7; Tue, 17 Jul 2012 21:11:58 +0200 (CEST) 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 hFNdgKQmAgcc; Tue, 17 Jul 2012 21:11:58 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 462AB1435A9C0; Tue, 17 Jul 2012 21:11:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3604D7DA-3A1F-475F-8EB1-1787BF8A3023@vpnc.org> Date: Tue, 17 Jul 2012 21:11:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com> <3604D7DA-3A1F-475F-8EB1-1787BF8A3023@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:11:12 -0000 Thanks! Patrik On 17 jul 2012, at 21:06, Paul Hoffman wrote: > On Jul 17, 2012, at 11:54 AM, Patrik F=E4ltstr=F6m wrote: >=20 >> Is this existence of this parameter for you a blocking factor for = this document? >=20 > I thought I was clear in my earlier message: no, not blocking. I bring = it up now because it is a useless addition that is trivial to remove. >=20 >> I do not mind if you expand a bit because I must as shepherd of this = document understand whether what you feel is something that still is in = the rough part of rough consensus, and if so that your view should be = paused until there is IETF last call and your input goes to IESG. >=20 > I say "useless" because, unlike NAPTR, the ordering of the lists is = optional. Because of this, the optionality of the preference ordering = makes the ordering useless. That is, if I say I know "SHA1, SHA256" you = don't know if I prefer SHA1 (because it's shorter, and I don't care = about anything above 60 bits of strength) or whether I have no = preference and listed them in numeric order or whether that order was = set by my software. That is, you cannot determine if my order is = surprising or uninteresting. This invalidates any value to the ordering. >=20 > If the WG leaves in the ordering, I believe that we need to add = "however, interpreting the order in answers will lead to wrong = conclusions". If I'm wrong and someone can show how a recipient can tell = the difference between answers that were ordered on purpose and those = that were not, that's great: we can add it to the draft. >=20 >> I can understand if you see these kind of parameters in DNS "go = away", but so far we have sort of used them in many RR Types, and maybe = what you ask for is a generic change in how we design new RR Types. But = the question is whether *THIS* document should be where we take that = step on "generic design decisions". >=20 > I do *not* want the parameters to go away: I said that I support the = publication of this document. All I am saying is that the optional = ordering is useless and will cause problems for validators ("where do I = read why I should have a preference") and zones who make false = assumptions on the order seen. >=20 > --Paul Hoffman >=20 >=20 From marka@isc.org Tue Jul 17 18:04:52 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1034B11E80C0 for ; Tue, 17 Jul 2012 18:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEA4n+OtYTGd for ; Tue, 17 Jul 2012 18:04:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 88BCA11E8079 for ; Tue, 17 Jul 2012 18:04:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id DA0B6C957F; Wed, 18 Jul 2012 01:05:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fd:f66e:81aa:fcdf]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E55BE216C33; Wed, 18 Jul 2012 01:05:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 33355229F0C0; Wed, 18 Jul 2012 11:05:23 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> In-reply-to: Your message of "Tue, 17 Jul 2012 09:23:55 MST." <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> Date: Wed, 18 Jul 2012 11:05:22 +1000 Message-Id: <20120718010523.33355229F0C0@drugs.dv.isc.org> Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 01:04:52 -0000 Sending a superset of the client's and recursive servers supported algorithms is a *bad* idea. DNSSEC only works reliably when both the recursive server *and* down stream clients can validate responses. By having the recursive server send a superset, authoritative servers will stop using algorithms sooner than they should. Instead of sending the superset a server should send the intersection of the clients + servers supported algorithms. This may result in a empty list. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Tue Jul 17 18:17:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77C121F8567 for ; Tue, 17 Jul 2012 18:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFn3tVzrkQrk for ; Tue, 17 Jul 2012 18:17:21 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D43F21F8569 for ; Tue, 17 Jul 2012 18:17:20 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6I0W3bx069506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2012 17:32:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120718010523.33355229F0C0@drugs.dv.isc.org> Date: Tue, 17 Jul 2012 18:18:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <20120718010523.33355229F0C0@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1278) Cc: DNSEXT Working Group Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 01:17:22 -0000 On Jul 17, 2012, at 6:05 PM, Mark Andrews wrote: > Sending a superset of the client's and recursive servers supported > algorithms is a *bad* idea. DNSSEC only works reliably when both > the recursive server *and* down stream clients can validate responses. > By having the recursive server send a superset, authoritative servers > will stop using algorithms sooner than they should. Instead of > sending the superset a server should send the intersection of the > clients + servers supported algorithms. This may result in a empty > list. What is the context for this comment? I never said anything about = sending a superset of the supported algorithm list. The only place = "superset" is mentioned in the draft does not apply above. --Paul Hoffman= From marka@isc.org Tue Jul 17 19:03:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9221F846C for ; Tue, 17 Jul 2012 19:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvZj5MzpFArV for ; Tue, 17 Jul 2012 19:03:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 80EB521F8464 for ; Tue, 17 Jul 2012 19:03:07 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 821E05F99A1; Wed, 18 Jul 2012 02:03:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fd:f66e:81aa:fcdf]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8883E216C36; Wed, 18 Jul 2012 02:03:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id BE669229FBCC; Wed, 18 Jul 2012 12:03:32 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <20120718010523.33355229F0C0@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 17 Jul 2012 18:18:06 MST." Date: Wed, 18 Jul 2012 12:03:31 +1000 Message-Id: <20120718020332.BE669229FBCC@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 02:03:08 -0000 In message , Paul Hoffman writes : > On Jul 17, 2012, at 6:05 PM, Mark Andrews wrote: > > > Sending a superset of the client's and recursive servers supported > > algorithms is a *bad* idea. DNSSEC only works reliably when both > > the recursive server *and* down stream clients can validate responses. > > By having the recursive server send a superset, authoritative servers > > will stop using algorithms sooner than they should. Instead of > > sending the superset a server should send the intersection of the > > clients + servers supported algorithms. This may result in a empty > > list. > > What is the context for this comment? I never said anything about = > sending a superset of the supported algorithm list. The only place = > "superset" is mentioned in the draft does not apply above. > > --Paul Hoffman= If the client did set the DO bit and the option(s) in the query, the validating recursive resolver MUST include the option(s) based on the setting of the CD bit. If the CD bit is set, the validating recursive resolver MUST include the option(s) based on the client query or a superset of the client option(s) list and the validator's own list (if different). If the CD bit is not set, the validating recursive resolver MAY copy the client option(s) or substitute its own option list. Part of the problem here is that measuring what "end-system" support is pointless, we really need to be measuring what the DNSSEC validation path supports or else you won't meet the purpose as outlined in the introduction. These proposed EDNS options serve to measure the acceptance and use of new digital signing algorithms. These signaling options can be used by zone administrators as a gauge to measure the successful deployment of code that implements newly deployed digital signature algorithm, DS hash and NSEC3 hash algorithm used with DNSSEC. A zone administrator is able to determine when to stop signing with a superseded algorithm when the server sees that a significant number of its clients signal that they are able to accept the new algorithm. Note that this survey may be conducted over the period of years before a tipping point is seen. Part of the problem here is a myth that you can have reliable DNSSEC without recursive servers validating results. This has resulted in "always set CD=1" and making decision like those above based on what CD was set to in the request. It also has skew the thinking here that you can ignore the rest of the DNSSEC validation path and get meaningful statistics. Just have recursive server send the intersection set of supported algorithms as seen in the last X seconds. Where X is somewhere between 1 hour and a week. This can easily be done by having a list of algorithms supported by the server and whenever you get a incoming query with one of these options set but without one of these algorithms you reset a counter to expire after X seconds for that algorithm. When you send a upstream query you send only those algorithms that which don't have a expiry timer running. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From yoshiro.yoneya@jprs.co.jp Wed Jul 18 01:51:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEDF21F8604 for ; Wed, 18 Jul 2012 01:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4disETVHNz8 for ; Wed, 18 Jul 2012 01:51:45 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC2621F860D for ; Wed, 18 Jul 2012 01:51:44 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q6I8qQEQ006973 for ; Wed, 18 Jul 2012 17:52:31 +0900 X-AuditID: ac120820-b7fe56d000000cec-0b-5006794fb34f Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 47.6D.03308.F4976005; Wed, 18 Jul 2012 17:52:31 +0900 (JST) Date: Wed, 18 Jul 2012 17:52:26 +0900 From: Yoshiro YONEYA To: dnsext@ietf.org Message-Id: <20120718175226.1f2da149fbbe6acd6944d36b@jprs.co.jp> In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsWyRoiFT9e/ki3A4O0BAYvdTY9YHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8enSLfaCfxwVX5cpNzDOY+9i5OSQEDCReHPvDCuELSZx4d56 ti5GLg4hgeOMEn+fHGIBSbAIqErcvnEHrIhNwEDi17LfTF2MHBwiAsISHa3iIGFhAUeJBd8X gpXwCjhI3HnxEWw+p4CdxLqDF9lAyoUEbCW2NbJBrLKQ+Hv3O9gUXgFBib87hEFMZgF1ifXz hEAqmAXkJZq3zmaewMg3C6FoFkLRLCRFCxiZVzHK5Kel6Ran5qUU56YbGOqVVObrZRUUFesl g+hNjOCQ4lDYwTjjlMEhRgEORiUeXo/TrAFCrIllxZW5hxglOZiURHmPlLEFCPEl5adUZiQW Z8QXleakFh9ilOBgVhLhvRYHlONNSaysSi3Kh0lJc7AoifMeP7vDT0ggPbEkNTs1tSC1CCYr w8GhJMFbUgHUKFiUmp5akZaZU4KQZuLgBBnOAzT8IEgNb3FBYm5xZjpE/hSjpJQ4byNIQgAk kVGaB9f7ilEc6AVh3h6QLA8wPcB1vQIayAQ0kLsYbGBJIkJKqoHR8vg/2SW1PIIFE/X3brl3 Mujg6/zw7zcvK6xQP7wiVYxJYamOgNPUu4phz6XPfVjdKX3Z/8ebqUpe8U9M6vrX/tK+feW3 teajm/Vv5Hafk+ZkvrDl7TSHbMnIbt1qxVwe/WUNPjW735wyfeX7geXAlSNBl6b1ax1mjjnA EDkt5KT+7zvppndzlViKMxINtZiLihMB4kIJiMwCAAA= Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:51:46 -0000 Hi, I read the draft and followings are my comments. - This kind of signaling mechanism is very useful especially for critical zone operators such as Root and TLD. Please move forward. - In section 2, appearance of OPTION-CODEs are not limited. Appearance of each OPTION-CODE (TBD1, TBD2 and TBD3) must be explicitly limited to once to avoid confusion and packet size inflation. Regards, -- Yoshiro YONEYA On Tue, 17 Jul 2012 15:00:02 +0200 Patrik Fältström wrote: > All, > > As this was announced on June 14, 2012, and Scott Rose immediately followed up with an announcement (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and there have been exactly zero comments I am a bit shy of declaring victory. > > Can I get please at least three people that have seen this version, read it, and support it moving forward (part from myself and the authors of the document? > > Patrik > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From olaf@NLnetLabs.nl Wed Jul 18 03:32:45 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4821F8663 for ; Wed, 18 Jul 2012 03:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-W3YL0lEDpz for ; Wed, 18 Jul 2012 03:32:44 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C42CF21F8658 for ; Wed, 18 Jul 2012 03:32:43 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6IAXS5X084928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jul 2012 12:33:29 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1342607610; bh=uXSyyPeBlaG0BIXu3tfuSZITCDSmfqvEYLFR/xilFJ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=erNaqBxHSz3p/Ik06B0REttl0OqPsU9AgWcnr8ev6X3c82x1f2vEIlgByyfAPhpef gKkVt+0715jbgldxbGdBig3poP9/YIiVvIFjluvG2DpQeXeoKEWfH695nawK6nJAgo 6dpMd6+xIDc+MCVORT2XNbIWKCe3CldgvDScJKnQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_006D2804-4AE9-4E34-9037-7340D012F6E7"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> Date: Wed, 18 Jul 2012 12:33:27 +0200 Message-Id: <7CEF1C74-1003-4E0A-9EDF-FD91EA52A64E@NLnetLabs.nl> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 18 Jul 2012 12:33:29 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 10:32:45 -0000 --Apple-Mail=_006D2804-4AE9-4E34-9037-7340D012F6E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_8AEF5C87-E36D-4A99-B800-FADB5BE376FA" --Apple-Mail=_8AEF5C87-E36D-4A99-B800-FADB5BE376FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 17, 2012, at 3:00 PM, Patrik F=E4ltstr=F6m wrote: > All, >=20 > As this was announced on June 14, 2012, and Scott Rose immediately = followed up with an announcement = (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and = there have been exactly zero comments I am a bit shy of declaring = victory. >=20 > Can I get please at least three people that have seen this version, = read it, and support it moving forward (part from myself and the authors = of the document? >=20 Although I have my doubts about the utility of the mechanism itself I = believe it is rather harmless.=20 However, I would like to see to it that there is no perception that the = implementation and use of this mechanism is not needed to be 'DNSSEC = compliant' I would like to see a sentence in the introduction added to the = introduction, as last sentence: "The implementation and use of the mechanism described herein is = OPTIONAL." --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_8AEF5C87-E36D-4A99-B800-FADB5BE376FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
All,

As this was announced on June 14, 2012, = and Scott Rose immediately followed up with an announcement (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) = and there have been exactly zero comments I am a bit shy of declaring = victory.

Can I get please at least three people that have seen = this version, read it, and support it moving forward (part from myself = and the authors of the = document?



Although= I have my doubts about the utility of the mechanism itself I believe it = is rather harmless. 

However, I would like = to see to it that there is no perception that the implementation and use = of this mechanism is not needed to be 'DNSSEC = compliant'

I would like to see a sentence in the = introduction added to the introduction, as last sentence:
"The = implementation and use of the mechanism described herein is = OPTIONAL."


--Olaf


Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_8AEF5C87-E36D-4A99-B800-FADB5BE376FA-- --Apple-Mail=_006D2804-4AE9-4E34-9037-7340D012F6E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJQBpD3AAoJEFRqER47aqpkSbwP/0kxTSbuhUptbBIi43jz+JDE OVdsZmTL7KtiHSPNBTfertdAeuTj5KQo14YU07/Xw01zB1ni5CvO21IIiYUbJcYr lqfGlnZbiqZbqWyPgFF/43B8IwJYfK6CveIuwuWWRMWcNJpr7LnJXC4BtC8r7uAc 0tqsOjzY/5uItjlteTnesRtX2vZZMp71J5yySJYyqdNczUl11t9iqjKz81vV1HAD 5CNEjXm5mz4Z+YGeXOrSIbgniSpgfzr8pVW7RObHy/i3t5dOiZoyOO2DitRubbWs 394HVJV9dtraqSsMLYCbtifuaysfbZKMGSkjgxUwIcNKxJ8gEHSpPsg95uAPX+FJ VFbf3BX+vt3BGtHXMAuk3p1QcBsGNitheaZevWt1KYKAwC+dtmOGFF0fsfCLeyJe dH9SLFvxZijRH1l2Eji5T5WQqlP8z7HvKRoD8IoemTeYye9PVe+Gm1XdqLdFRJ73 DXsJ0c8uvQoIV3SaFWvbe+zL9u14WjsChDEhOtifl26OspvA7OGrRBZnUYh3r16T U07zsHGnr5A6BmX2eLRKHHI/8Vbph1thXCZJ2TOAi9ipEnEwWT7UQX8OCVfMpvBx 3YKxt2VMhneQ3uaEaVMCEdx9uDQd4Ww3+QEz+ItbHPOjwc7/cQy82UNrwFMaaWq5 j26QT+HKtM6V54vu/qhl =p331 -----END PGP SIGNATURE----- --Apple-Mail=_006D2804-4AE9-4E34-9037-7340D012F6E7-- From wouter@nlnetlabs.nl Wed Jul 18 07:16:27 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9CC21F878A for ; Wed, 18 Jul 2012 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyn6GXzVtgnR for ; Wed, 18 Jul 2012 07:16:26 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8821F869C for ; Wed, 18 Jul 2012 07:16:25 -0700 (PDT) Received: from [192.168.254.2] (82-170-121-249.ip.open.net [82.170.121.249]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q6IEHCju049354 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2012 16:17:13 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1342621034; bh=gMhJkIlQILIkodHgCKtk6icE7lt9nPLTmYWzmT/jwgI=; h=Date:From:To:Subject:References:In-Reply-To; b=qB6AP3lt0aWKp+KHCv5DuQtwBe/kJ0eCjCDDtmXzHeWNZhs6k+garnERvHYNSUukK dZZNTd3GfZtQL5F01S4tRmcporSA+PCjAyYbCyE0aBGgKfTMRUvtqUBlP6dii2GTZp 61V2DIwSufA+IaF1gC5/emLxRNmPOyJIYV0bppms= Message-ID: <5006C56C.2080800@nlnetlabs.nl> Date: Wed, 18 Jul 2012 16:17:16 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <7CEF1C74-1003-4E0A-9EDF-FD91EA52A64E@NLnetLabs.nl> In-Reply-To: <7CEF1C74-1003-4E0A-9EDF-FD91EA52A64E@NLnetLabs.nl> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 18 Jul 2012 16:17:13 +0200 (CEST) Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:16:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 07/18/2012 12:33 PM, Olaf Kolkman wrote: > > On Jul 17, 2012, at 3:00 PM, Patrik Fältström wrote: > >> All, >> >> As this was announced on June 14, 2012, and Scott Rose >> immediately followed up with an announcement >> (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) >> >> and there have been exactly zero comments I am a bit shy of >> declaring victory. >> >> Can I get please at least three people that have seen this >> version, read it, and support it moving forward (part from myself >> and the authors of the document? >> > > > Although I have my doubts about the utility of the mechanism itself > I believe it is rather harmless. > > However, I would like to see to it that there is no perception > that the implementation and use of this mechanism is not needed to > be 'DNSSEC compliant' > > I would like to see a sentence in the introduction added to the > introduction, as last sentence: "The implementation and use of the > mechanism described herein is OPTIONAL." > I like the document, and it has improved significantly (yay!), but the troublesome section today is indeed section 3.2.1. Validating Recursive Resolvers. Why is there a difference if the CD flag is set? The validator could well verify signatures, even if CD flag is set, but with the CD flag set would not withhold bogus data with SERVFAIL. Then the set of algorithms for the validator may still be important - it would not stop the data from being seen by the customer - but it would disable the validator from picking the 'right DNSSEC signatures' out of multiple candidates if it does not support the signing algorithm. I would also prefer to (be allowed to) answer from cache even if the previous query had a different list of supported algorithms (the answer from the authority is the same), if the TTL has not expired, of course. The EDNS option codes in the query may not be supported by the upstream server. What is the expected result if the upstream cache/authority does not support it, and how to deal with it? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBsVrAAoJEJ9vHC1+BF+N6ecP/A/shRXVS4A5T721Ww99HKXx yT9W0Yko8NkJVUaqiVuG/et93v8hfthPeIXjdbR0oXYGHfNesM8jf7GataUpm57Q nDRNgANJuQhxjjQwkbf4fHSbIK9koYaa6AQgXIXIddQP3CN5FJ7nYlSvEGivvR3O +F42qdNOgTsNpEha3jTvSgDN3i7CjwDls/UFBXmuD3KUHm2rpD84EDBR/x9gUEG0 PNP7pnsGgRCHCz+iZm0l6qjPqWhjlEf+IhCumustrze0csVwaAlwpjRNaoOP6IMK lqL6WL9oxobsnb7Y289/X5ipVLRbcxA7suywSEryoOMUHgq4gNufv4Y7lhB6CdBE btO3gz4kXjUASGKNbBG/6Orvr/Ruqgjyrq4yW8LWI65RyRGUmRmAs3KIVCeUn3Mf 9nM+NREn7DiD7AxcCTmgMRqUxc70SgmwIisRbD7Z01uipu3+DoS6amwnfuBEx37s XXTdxLps1F88IOP00zOzvQyXw6BV6VENQbDRQevAECS0Zl5LkDqWPslPNwgoSYb7 Jepg3WL+uRom3Orx3jPw2SN07QitxCOHKuO5UrNdvmHgjaFpSSsx1PMki4TSpZOx rgvkyilwVuL3Jji9P03Z1MIYjz9X1obN0h3P6PMhxTN+Kd8gi+GTIauaOclrXbnW mlKr1tLz5C0B0JJ+1ovC =QK8C -----END PGP SIGNATURE----- From ajs@crankycanuck.ca Wed Jul 18 11:05:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B32A11E80D9 for ; Wed, 18 Jul 2012 11:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BjvvjQUHMNG for ; Wed, 18 Jul 2012 11:05:13 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD421F87B9 for ; Wed, 18 Jul 2012 11:05:12 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 314008A031 for ; Wed, 18 Jul 2012 18:06:03 +0000 (UTC) Date: Wed, 18 Jul 2012 14:06:01 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120718180601.GP340@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:05:15 -0000 Hi, Pete Resnick has a DISCUSS on this document. Addressing his comments requires significant text, so I wanted to confirm with the WG. I believe all of these are completely in line with what we intend, but with so many changes I thought it unwise to proceed without confirming. I've marked the items off with === delimiters === First, the paragraph This implementation status indication is only to be considered for implementation, not deployment or operations. Operators are free to deploy any digital signature algorithm available in implementations or algorithms chosen by local security policies. This status is to measure compliance to this document only. in section 1 would be removed completely. Pete is not the only AD who has objected to this. Any objection? === Pete's suggestion is to change the column headers in section 2.2 to titlecase, and add these definitions to the document (in 1.1): - "Must Implement" means that the algorithm MUST be used in order to interoperate with other implementations on the Internet. - "Must Not Implement" means that the algorithm MUST NOT be used so as to prevent the compromise of the DNS data; the algorithm has known weaknesses and is not considered safe to use anymore. - "Recommended To Implement" means that the algorithm SHOULD be used in order to interoperate with other implementations on the Internet, though there may be exist valid reasons in particular circumstances not to do so. An implementer must understand and weigh the full implications of choosing not to implement this particular algorithm. - "Optional" means that the algorithm MAY be implemented, but that all implementations MUST be prepared to interoperate with implementations that do or do not implement this algorithm. This seems reasonable to me, and solves the problem that the words otherwise looked like slightly unusual 2119 keywords. Any objection? === The paragraph This table does not list the Reserved values in the IANA registry table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID (254). These values may relate to more than one algorithm and are therefore up to the implementer's discretion. Their implementation (or lack thereof) therefore cannot be included when judging compliance to this document. would be rewritten to say This table does not list the Reserved values in the IANA registry table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID (254). These values may relate to more than one algorithm and are therefore up to the implementer's discretion. In that sense, they might be considered optional, but their implementation (or lack thereof) has no bearing on interoperability and therefore they do not appear here. Ok? === Finally, because this says "Applicability statement" on it, and it appears in fact to be one, Pete wants to say it goes on the standards track as PS. Any objection? Otherwise, we need a new title. This decision is nominally supposed to be up to the chairs anyway, but I recall some discussion about this before so I thought I'd ask whether anyone has strong feelings. I believe that covers every planned change. Comments would be appreciated as soon as possible, and in any case not later than one week from now. If nobody objects, these changes will all be made. Best, A -- Andrew Sullivan ajs@crankycanuck.ca From paul.hoffman@vpnc.org Wed Jul 18 15:59:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B237F11E80A0 for ; Wed, 18 Jul 2012 15:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jhFHBtx5+j7 for ; Wed, 18 Jul 2012 15:59:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8690521F859B for ; Wed, 18 Jul 2012 15:59:16 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6IM6Lq9074732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jul 2012 15:06:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120718180601.GP340@crankycanuck.ca> Date: Wed, 18 Jul 2012 15:57:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120718180601.GP340@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1278) Cc: dnsext@ietf.org Subject: Re: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:59:17 -0000 On Jul 18, 2012, at 11:06 AM, Andrew Sullivan wrote: > Hi, >=20 > Pete Resnick has a DISCUSS on this document. Addressing his comments > requires significant text, so I wanted to confirm with the WG. I > believe all of these are completely in line with what we intend, but > with so many changes I thought it unwise to proceed without > confirming. =20 Let me be clear here: What Pete wants is a fundamental change from what = the WG and the IETF consensus was. The consensus was on "need to = implement, not deploy"; what Pete is asking for is "deploy". This fundamental change makes absolutely no sense for this document. If = Pete insists that we can only say what is mandatory to deploy, we need = to start over again. > I've marked the items off with =3D=3D=3D delimiters >=20 > =3D=3D=3D >=20 > First, the paragraph >=20 > This implementation status indication is only to be considered for > implementation, not deployment or operations. Operators are free to > deploy any digital signature algorithm available in implementations > or algorithms chosen by local security policies. This status is to > measure compliance to this document only. >=20 > in section 1 would be removed completely. Pete is not the only AD who > has objected to this. Any objection? Yes. Without this paragraph, someone who runs a zone and sees this RFC, = but does not know the sketchy IETF lore of "mandatory to implement does = not mean mandatory to deploy" will get a very wrong impression. Pete's stated objection at = is: +++ I think the above paragraph is either wrong or meaningless. I don't know = what it means to say that the implementation status is for = implementation but not deployment. The reason that one "MUST IMPLEMENT" = RSASHA1 is that an implementation will not interoperate with other = DNSSEC deployments if it doesn't allow the use of RSASHA1. Similarly, = the reason it is "RECOMMENDED TO IMPLEMENT" RSASHA1-NSEC3-SHA1 is that = you won't interoperate in DNSSEC if you don't do it, but there are = circumstances under which you might not use it. The reason you "MUST NOT = IMPLEMENT" RSAMD5 is because it is a broken algorithm and use of it will = cause damage. These are not about implementation; they are absolutely = about interoperation. Operators *are* free to deploy anything they like, = but that's because there are no protocol police and you are free to = ignore the considered consensus of the IETF. But the considered = consensus of the IETF is that these are protocol requirements to allow = for interoperation. The IETF is *not* supposed to be writing compliance = documents. Please strike the paragraph in it's entirety. See next bit on = 2119 keywords for more on this. +++ I disagree that "Operators are free to deploy..." is a "compliance = document". In fact, it is the opposite. If there was an IETF doc that = this doc could point to that says "here is what an implementation = requirement means", that would be grand, but we don't have one, so we = need to say it here. Further, "The reason that one "MUST IMPLEMENT" RSASHA1 is that an = implementation will not interoperate with other DNSSEC deployments if it = doesn't allow the use of RSASHA1" is factually wrong. If someone doesn't = follow the "MUST IMPLEMENT" there, they can still interoperate with = other deployments as long as the two deployments use the same = less-than-mandatory signing algorithm. The "MUST IMPLEMENT" is there so = that every implementation is know to be able to interoperate with other = implementations *if they all pick a common algorithm*. Further, "The reason you "MUST NOT IMPLEMENT" RSAMD5 is because it is a = broken algorithm and use of it will cause damage" is also incorrect. No = one has shown a single plausible attack on RSAMD5 in the DNSSEC = environment (which is completely different than the PKIX-with-sub-CAs = environment where it has proven to be disastrous). The reason it is = there is because of voodoo that is harmless. Seriously: I believe Pete is dead wrong on this. > =3D=3D=3D >=20 > Pete's suggestion is to change the column headers in section 2.2 to > titlecase, and add these definitions to the document (in 1.1): >=20 > - "Must Implement" means that the algorithm MUST be used in order > to interoperate with other implementations on the Internet. >=20 > - "Must Not Implement" means that the algorithm MUST NOT be used so > as to prevent the compromise of the DNS data; the algorithm has > known weaknesses and is not considered safe to use anymore. >=20 > - "Recommended To Implement" means that the algorithm SHOULD be > used in order to interoperate with other implementations on the > Internet, though there may be exist valid reasons in particular > circumstances not to do so. An implementer must understand and > weigh the full implications of choosing not to implement this > particular algorithm. >=20 > - "Optional" means that the algorithm MAY be implemented, but that > all implementations MUST be prepared to interoperate with > implementations that do or do not implement this algorithm. >=20 > This seems reasonable to me, and solves the problem that the words > otherwise looked like slightly unusual 2119 keywords. Any objection? Very strong objections. The first and third are clearly at odds with = each other. If I only validate RSASHA1 and you sign with RSASHA256, we = will not interoperate. Pete may not understand that "be used" means very = different things for signers and validators. And, again, the "Must Not = Implement" description is false. There are no known weaknesses with = signing RSA with MD5 for DNSSEC; there are vague concerns, and we know = we have better algorithms that everyone uses, so we might as well just = get rid of it. > =3D=3D=3D >=20 > The paragraph >=20 > This table does not list the Reserved values in the IANA registry > table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID > (254). These values may relate to more than one algorithm and are > therefore up to the implementer's discretion. Their implementation > (or lack thereof) therefore cannot be included when judging > compliance to this document. >=20 > would be rewritten to say >=20 > This table does not list the Reserved values in the IANA registry > table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID > (254). These values may relate to more than one algorithm and are > therefore up to the implementer's discretion. In that sense, they > might be considered optional, but their implementation (or lack > thereof) has no bearing on interoperability and therefore they do = not > appear here. >=20 > Ok? Yes. > =3D=3D=3D >=20 > Finally, because this says "Applicability statement" on it, and it > appears in fact to be one, Pete wants to say it goes on the standards > track as PS. Any objection? Otherwise, we need a new title. This > decision is nominally supposed to be up to the chairs anyway, but I > recall some discussion about this before so I thought I'd ask whether > anyone has strong feelings. Sure. > I believe that covers every planned change. Comments would be > appreciated as soon as possible, and in any case not later than one > week from now. If nobody objects, these changes will all be made. Again: very strong objections to the first two. They go against the = consensus of the WG and IETF. --Paul Hoffman From patrik@frobbit.se Thu Jul 19 03:13:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CE21F8771 for ; Thu, 19 Jul 2012 03:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4sWkEvYlpef for ; Thu, 19 Jul 2012 03:13:24 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E8D4C21F876A for ; Thu, 19 Jul 2012 03:13:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 7F20E1437CB92; Thu, 19 Jul 2012 12:14:14 +0200 (CEST) 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 evg1CHKLL6A0; Thu, 19 Jul 2012 12:14:14 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 54AD91437CB88; Thu, 19 Jul 2012 12:14:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_D7D3038B-E290-4286-9ACB-E4FC3691731A"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 19 Jul 2012 12:14:13 +0200 Message-Id: References: <20120718180601.GP340@crankycanuck.ca> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) Cc: Andrew Sullivan , dnsext@ietf.org Subject: Re: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:13:24 -0000 --Apple-Mail=_D7D3038B-E290-4286-9ACB-E4FC3691731A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 jul 2012, at 00:57, Paul Hoffman wrote: > On Jul 18, 2012, at 11:06 AM, Andrew Sullivan wrote: >=20 >> Hi, >>=20 >> Pete Resnick has a DISCUSS on this document. Addressing his comments >> requires significant text, so I wanted to confirm with the WG. I >> believe all of these are completely in line with what we intend, but >> with so many changes I thought it unwise to proceed without >> confirming. =20 >=20 > Let me be clear here: What Pete wants is a fundamental change from = what the WG and the IETF consensus was. The consensus was on "need to = implement, not deploy"; what Pete is asking for is "deploy". >=20 > This fundamental change makes absolutely no sense for this document. = If Pete insists that we can only say what is mandatory to deploy, we = need to start over again. I agree with this. I.e. that what Pete asks for is different from WG = consensus. Patrik --Apple-Mail=_D7D3038B-E290-4286-9ACB-E4FC3691731A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAlAH3fYACgkQrMabGguI1801CQCghC9iIYgB25SE5xHV22dJbz95 3acAn3/gsy0u4uRl5aqxVZVrG4ZtLhVg =GjCb -----END PGP SIGNATURE----- --Apple-Mail=_D7D3038B-E290-4286-9ACB-E4FC3691731A-- From scottr.nist@gmail.com Thu Jul 19 06:26:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32D121F86B5 for ; Thu, 19 Jul 2012 06:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEZYg0XbtbD5 for ; Thu, 19 Jul 2012 06:26:08 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D821F86AF for ; Thu, 19 Jul 2012 06:26:07 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jul 2012 09:26:52 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Thu, 19 Jul 2012 09:26:49 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q6JDQxpf000801; Thu, 19 Jul 2012 09:26:59 -0400 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD536C6F-4160-4543-930F-8A121B27B8D1" From: Scott Rose In-Reply-To: Date: Thu, 19 Jul 2012 09:26:59 -0400 Message-ID: <408A5182-25C0-42CB-A237-F56C5F078FDC@gmail.com> References: <20120718180601.GP340@crankycanuck.ca> To: X-Mailer: Apple Mail (2.1278) Cc: Andrew Sullivan Subject: Re: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:26:10 -0000 --Apple-Mail=_DD536C6F-4160-4543-930F-8A121B27B8D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Jul 19, 2012, at 6:14 AM, Patrik F=E4ltstr=F6m wrote: >=20 > On 19 jul 2012, at 00:57, Paul Hoffman wrote: >=20 >> On Jul 18, 2012, at 11:06 AM, Andrew Sullivan wrote: >>=20 >>> Hi, >>>=20 >>> Pete Resnick has a DISCUSS on this document. Addressing his = comments >>> requires significant text, so I wanted to confirm with the WG. I >>> believe all of these are completely in line with what we intend, but >>> with so many changes I thought it unwise to proceed without >>> confirming. =20 >>=20 >> Let me be clear here: What Pete wants is a fundamental change from = what the WG and the IETF consensus was. The consensus was on "need to = implement, not deploy"; what Pete is asking for is "deploy". >>=20 >> This fundamental change makes absolutely no sense for this document. = If Pete insists that we can only say what is mandatory to deploy, we = need to start over again. >=20 > I agree with this. I.e. that what Pete asks for is different from WG = consensus. >=20 And different from the initial intent of the document. This changes the = document significantly, but if there is WG consensus on the change I can = edit the doc. =20 Scott > Patrik >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_DD536C6F-4160-4543-930F-8A121B27B8D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

On = 19 jul 2012, at 00:57, Paul Hoffman wrote:

On Jul 18, 2012, at 11:06 AM, Andrew Sullivan = wrote:

Hi,

Pete Resnick has a DISCUSS on = this document.  Addressing his = comments
requires significant text, so I = wanted to confirm with the WG. =  I
believe all of these are completely in line with what we = intend, but
with so many changes I thought = it unwise to proceed without
confirming. =  

Let me be clear = here: What Pete wants is a fundamental change from what the WG and the = IETF consensus was. The consensus was on "need to implement, not = deploy"; what Pete is asking for is = "deploy".

This = fundamental change makes absolutely no sense for this document. If Pete = insists that we can only say what is mandatory to deploy, we need to = start over again.

I agree with this. I.e. that what = Pete asks for is different from WG = consensus.


And different = from the initial intent of the document.  This changes the document = significantly, but if there is WG consensus on the change I can edit the = doc. =  

Scott


=   Patrik

_______________________________________________<= br>dnsext mailing list
dnsext@ietf.org
https://www.ietf.or= g/mailman/listinfo/dnsext

= --Apple-Mail=_DD536C6F-4160-4543-930F-8A121B27B8D1-- From fujiwara@jprs.co.jp Thu Jul 19 13:28:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE821F863D for ; Thu, 19 Jul 2012 13:28: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZGR+R97iyDZ for ; Thu, 19 Jul 2012 13:28:53 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 005D721F8634 for ; Thu, 19 Jul 2012 13:28:52 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q6JKTWYh014884; Fri, 20 Jul 2012 05:29:32 +0900 X-AuditID: ac120820-b7fe56d000000cec-49-50086e2c34b6 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id C9.F2.03308.C2E68005; Fri, 20 Jul 2012 05:29:32 +0900 (JST) Date: Fri, 20 Jul 2012 05:29:32 +0900 (JST) Message-Id: <20120720.052932.112608338.fujiwara@jprs.co.jp> To: patrik@frobbit.se From: fujiwara@jprs.co.jp In-Reply-To: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsWyRoiFT1cnjyPAYNMzI4vdTY9YLT69+8ro wOTxdtJmJo8lS34yBTBFcdmkpOZklqUW6dslcGX0HbjEUjCbp+LR511MDYwXOLsYOTkkBEwk 5jw5yA5hi0lcuLeerYuRi0NI4CSjxOmXX5lAEiwC2hLvVu4Es3kFrCVenz0DZosIiEq8+vya DcRmFhCW+LnrKzOILSzgKLHg+0JWEJtNQFJi8+dWsDingJ3EuoMXgeo5gBbYSmxrZIPYaydx 4vkKVpAwr4CgxN8dwhATdSTOzWuDmq4tsWzha+YJjPyzEKpmIamahaRqASPzKkaZ/LQ03eLU vJTi3HQDQ72Syny9rIKiYr1kEL2JERyGHAo7GGecMjjEKMDBqMTD65jAESDEmlhWXJl7iFGS g0lJlPd8DlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG9OMlCONyWxsiq1KB8mJc3BoiTOe/zs Dj8hgfTEktTs1NSC1CKYrAwHh5IEr3IuUKNgUWp6akVaZk4JQpqJgxNkOA/QcAeQGt7igsTc 4sx0iPwpRkkpcV5fkIQASCKjNA+u9xWjONALwrzqIFkeYEqB63oFNJAJaCB3MRvIwJJEhJRU A2NKg+f0XalSlq+3sFqtc4qcojH9mQb/t3dS35evdf6+LKRg1jMhT6d7vm0TjlpHBVj1qayM 4rlj8Ojevqa2Tw42lw+eUvtnUuXiyXRUIW1FUJzxr85XrgnScwy9T6d4Wa9ot9874dDNPJ0b Dep9W385bBZ1YF4acivNuCR/S8HLFXKLWU5ckVZiKc5INNRiLipOBABoCTTi5gIAAA== Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:28:54 -0000 Hi, = I read the document. I agree to define EDNS0 option code because it is not used well. As a private user, I oppose to set DAU, DHU and N3U in my resolvers. Or if it is not mandatry, I will disabie this function. There are three reasons. They may be already discussed. My comment may be too late. 1. Setting DAU, DHU and N3U may leak resolvers information to malicious servers. 2. Setting them increases query packet size, 25% or 50%. DNSSEC algorithms will increase, but we cannot disable old algorithm= s. We cannot decrease number of algorithms. 3. Setting DAU, DHU and N3U does not effect DNSSEC validation. It is useless to use DNSSEC. I agree the draft if the implementation is not required and some concerns are added at "Security considerations" or another part. Regards, -- Kazunori Fujiwara, JPRS > From: Patrik F=E4ltstr=F6m > All, > = > As this was announced on June 14, 2012, and Scott Rose immediately fo= llowed up with an announcement (http://www.ietf.org/mail-archive/web/dn= sext/current/msg12514.html) and there have been exactly zero comments I= am a bit shy of declaring victory. > = > Can I get please at least three people that have seen this version, r= ead it, and support it moving forward (part from myself and the authors= of the document? > = > Patrik > = > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > = From nweaver@icsi.berkeley.edu Thu Jul 19 13:54:33 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB46721F86B6 for ; Thu, 19 Jul 2012 13:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikloMUW+ChdG for ; Thu, 19 Jul 2012 13:54:32 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 68E1221F869A for ; Thu, 19 Jul 2012 13:54:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6B9C12C400A; Thu, 19 Jul 2012 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LBU0AHHxjGTu; Thu, 19 Jul 2012 13:55:25 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 370652C4003; Thu, 19 Jul 2012 13:55:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: <5006C56C.2080800@nlnetlabs.nl> Date: Thu, 19 Jul 2012 13:55:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <7CEF1C74-1003-4E0A-9EDF-FD91EA52A64E@NLnetLabs.nl> <5006C56C.2080800@nlnetlabs.nl> To: IETF DNSEXT WG X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:54:33 -0000 I like the document as well. One nit: Perhaps there should be language somewhere to the effect of = not honoring requests for obsoleted algorithms, to prevent this being = used for downgrade attacks. From Ray.Bellis@nominet.org.uk Fri Jul 20 05:46:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0021F85D7 for ; Fri, 20 Jul 2012 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.433 X-Spam-Level: X-Spam-Status: No, score=-9.433 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWtxj8y6oBFT for ; Fri, 20 Jul 2012 05:46:34 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 330F221F85A4 for ; Fri, 20 Jul 2012 05:46:32 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=2xwgm4PnKvqY5wurG0xm/ncYBl/QuKL+manENvJfneiuETPfOVpTJlth gUKryNyiIEtRjtdnN99pnfJnyq+pOeHSuyTYlh+VYYpoOXw2dTO8zqRx6 GTq6JS73ESF7dca; 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=1342788450; x=1374324450; 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=20Bellis=20 |Subject:=20Re:=20[dnsext]=20draft-ietf-dnsext-dnssec-alg o-signal-07.txt|Date:=20Fri,=2020=20Jul=202012=2012:47:26 =20+0000|Message-ID:=20|To:=20IETF=20DNSEXT=20WG=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20|In-Reply-To:=20<20120718020332.BE669229FBCC@ drugs.dv.isc.org>|References:=20<6EC11B57-B164-4214-AADE- E552D9B21753@frobbit.se>=0D=0A=20<85D2BE55-4028-468E-A07B -4F3B7406B68A@vpnc.org>=0D=0A=20<20120718010523.33355229F 0C0@drugs.dv.isc.org>=0D=0A=20=0D=0A=20<20120718020332.BE669229FBCC @drugs.dv.isc.org>; bh=c8lmlVv6dSKIq1cfFVbcFoHwg0ZqZIpYU8REB/nx6Ig=; b=P38u++tWcTP6MeHQWNn3W9DqidSK7ddAigmCo265dT2ScbhhVhDnmlW4 1ai2AdJHg/fTU9qFp0QNxQ6jqQerQQCKDKO7oSFcNY1ZWf6jMlfrYWD4m Akhxv4LnjvIXe7j; X-IronPort-AV: E=Sophos;i="4.77,623,1336345200"; d="scan'208";a="34245188" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 20 Jul 2012 13:47:28 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Fri, 20 Jul 2012 13:47:27 +0100 From: Ray Bellis To: IETF DNSEXT WG Thread-Topic: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt Thread-Index: AQHNZImHx/OAY7KCREWo8ykwZNWubJcyEcoA Date: Fri, 20 Jul 2012 12:47:26 +0000 Message-ID: References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <20120718010523.33355229F0C0@drugs.dv.isc.org> <20120718020332.BE669229FBCC@drugs.dv.isc.org> In-Reply-To: <20120718020332.BE669229FBCC@drugs.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 12:46:35 -0000 On 18 Jul 2012, at 03:03, Mark Andrews wrote: >=20 > Just have recursive server send the intersection set of supported > algorithms as seen in the last X seconds. Where X is somewhere > between 1 hour and a week. This can easily be done by having a > list of algorithms supported by the server and whenever you get a > incoming query with one of these options set but without one of > these algorithms you reset a counter to expire after X seconds for > that algorithm. When you send a upstream query you send only those > algorithms that which don't have a expiry timer running. I like this idea. It avoids this draft's problem with violating EDNS's "ho= p-by-hop only" semantics by decoupling the recursor->authority message from= any individual stub->recursor message. Ray p.s. did you actually mean "union" rather than "intersection" ? From iesg-secretary@ietf.org Mon Jul 23 14:05:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B7811E80A1; Mon, 23 Jul 2012 14:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFprmjo-J0Ch; Mon, 23 Jul 2012 14:05:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FBF11E80CC; Mon, 23 Jul 2012 14:05:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120723210539.4469.80039.idtracker@ietfa.amsl.com> Date: Mon, 23 Jul 2012 14:05:39 -0700 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates' to Proposed Standard (draft-ietf-dnsext-dnssec-registry-update-03.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 21:05:39 -0000 The IESG has approved the following document: - 'DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates' (draft-ietf-dnsext-dnssec-registry-update-03.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ Technical Summary The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. Working Group Summary The changes this draft makes were originally bound up with some changes from a previous WG draft that was not published. Some of the WG and, particularly, the IESG objected to the way that draft altered the registry; this draft and another one were the results. This draft is not bound up with the other draft, and makes the uncontroversial changes to the registry. Document Quality This draft makes no changes to any protocol, but cleans up a number of errors and omissions in the relevant registry. Personnel Andrew Sullivan is the Document Shepherd. Ralph Droms is the Responsible Area Director. From miekg@atoom.net Tue Jul 24 01:53:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD13121F8656 for ; Tue, 24 Jul 2012 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRL5DO993mzp for ; Tue, 24 Jul 2012 01:53:07 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25721F8648 for ; Tue, 24 Jul 2012 01:53:07 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 380EB40114; Tue, 24 Jul 2012 10:53:04 +0200 (CEST) Date: Tue, 24 Jul 2012 10:53:04 +0200 From: Miek Gieben To: dnsext List Message-ID: <20120724085304.GB730@miek.nl> Mail-Followup-To: dnsext List MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [dnsext] nsec/nsec3 whitepaper as i-d X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 08:53:16 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear colleagues, Last year Matthijs Mekking and I wrote a white paper explaining authenticat= ed denial of existence in the DNS. See this URL: https://www.sidn.nl/fileadmin/docs/PDF-files_UK/wp-2011-0x01-v2.pdf Several people have since asked us if we could massage this into an i-d (and eventually an RFC), so that it will get a wider exposure. Is this something this (dormant) WG is willing to take up? Regards, --=20 Miek Gieben http://mi= ek.nl --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAOYnAACgkQJYuFzziA0PYruACg385D45PLugnAq2AEuxMtDlYH ZXYAn14Hxs7NUz/j2zm30xDA+5LnTa0g =bMdW -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From ajs@anvilwalrusden.com Tue Jul 24 05:44:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4E321F8649 for ; Tue, 24 Jul 2012 05:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejn3rxpAGjIH for ; Tue, 24 Jul 2012 05:44:31 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C495121F8647 for ; Tue, 24 Jul 2012 05:44:31 -0700 (PDT) Received: from mail.yitter.info (nat-05-mht.dyndns.com [216.146.45.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 50A798A031 for ; Tue, 24 Jul 2012 12:44:30 +0000 (UTC) Date: Tue, 24 Jul 2012 08:44:30 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120724124430.GB5610@mail.yitter.info> References: <20120724085304.GB730@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120724085304.GB730@miek.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] nsec/nsec3 whitepaper as i-d X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:44:32 -0000 On Tue, Jul 24, 2012 at 10:53:04AM +0200, Miek Gieben wrote: > Is this something this (dormant) WG is willing to take up? No. We're not "dormant", we're "shutting down". Sorry. With my hat off, I'm actually a little dubious about the premise anyway. What makes you think that an RFC will get wider exposure than less-geeky modes of publication? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Tue Jul 24 08:07:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F821F861E for ; Tue, 24 Jul 2012 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvmo3HlQUM63 for ; Tue, 24 Jul 2012 08:07:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D95C621F85F0 for ; Tue, 24 Jul 2012 08:07:10 -0700 (PDT) Received: from [10.20.30.100] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6OEFtg1055244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Jul 2012 07:15:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <20120724124430.GB5610@mail.yitter.info> Date: Tue, 24 Jul 2012 08:07:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120724085304.GB730@miek.nl> <20120724124430.GB5610@mail.yitter.info> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] nsec/nsec3 whitepaper as i-d X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 15:07:11 -0000 On Jul 24, 2012, at 5:44 AM, Andrew Sullivan wrote: > On Tue, Jul 24, 2012 at 10:53:04AM +0200, Miek Gieben wrote: >> Is this something this (dormant) WG is willing to take up? >=20 > No. We're not "dormant", we're "shutting down". Sorry. >=20 > With my hat off, I'm actually a little dubious about the premise > anyway. What makes you think that an RFC will get wider exposure than > less-geeky modes of publication? I agree with Andrew about the "no" for the WG, but disagree with him = about not publishing it as an Internet-Draft and eventually as an RFC. = This type of paper is exactly what the ISE stream of RFCs is for. It = expands knowledge on some interesting Internet technologies and is = fairly well-written. --Paul Hoffman= From miekg@atoom.net Tue Jul 24 13:18:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1C21F8550 for ; Tue, 24 Jul 2012 13:18:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWv86LfE+KkD for ; Tue, 24 Jul 2012 13:18:02 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [IPv6:2001:7b8:32a::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5042421F8547 for ; Tue, 24 Jul 2012 13:18:02 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 53D583FFED; Tue, 24 Jul 2012 22:17:57 +0200 (CEST) Date: Tue, 24 Jul 2012 22:17:57 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120724201757.GA1661@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120724085304.GB730@miek.nl> <20120724124430.GB5610@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] nsec/nsec3 whitepaper as i-d X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:18:02 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting in "Re: [dnsext] nsec/nsec3 whitepaper ..." ] > I agree with Andrew about the "no" for the WG, but disagree with him about not publishing it as an Internet-Draft and eventually as an RFC. This type of paper is exactly what the ISE stream of RFCs is for. It expands knowledge on some interesting Internet technologies and is fairly well-written. An independent submission is probably the best way forward. Thanks. grtz Miek --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAPAvUACgkQJYuFzziA0PYHwwCeMvhl4nfrcjaBMakjQSPgBieP 2LoAoMx1K+0/BIbU1oLe8/nU2wkMMw1c =CaeN -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From rbarnes@bbn.com Mon Jul 30 10:18:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD2011E810C; Mon, 30 Jul 2012 10:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNO2LkCFCs+f; Mon, 30 Jul 2012 10:18:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 26FC911E80A4; Mon, 30 Jul 2012 10:18:39 -0700 (PDT) Received: from [128.89.254.164] (port=54153) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Svtbp-00022u-Ux; Mon, 30 Jul 2012 13:18:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20120619021211.GI32683@crankycanuck.ca> Date: Mon, 30 Jul 2012 10:18:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A7F5D7E-C3A8-4118-ADA1-C9CB814CDF72@bbn.com> References: <20120619021211.GI32683@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-dnsext-dnssec-bis-updates@tools.ietf.org, ietf@ietf.org, dnsext@ietf.org, IESG Subject: Re: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:18:41 -0000 Hey Andrew, Thanks for following up, and sorry for the lag. Thank goodness for IETF = meetings giving us time to process email :) Couple of responses inline. >> MAJOR: >>=20 >> 4.1. =20 >> It's not clear what the threat model is that this section is >> designed to address. If the zone operator is malicious, then it can >> simulate the necessary zone cut and still prove the non-existence of >> records in the child zone. >=20 > The problem here is not a malicious parent operator, but "an NSEC or > NSEC3 RR from an ancestor zone". In the original specification, an > attacker could use such an RR to prove the non-existence of some name > in a subordinate zone. That was the problem. (Remember, in DNS there > is a good chance that you are not talking to an authoritative server.) > If you have suggestions on ways to make that clearer, it'd be welcome. > The editors tried to come up with compact examples that would be > anything other than mystifying, and were unsuccessful. =20 I guess I still don't understand this. Aren't ancestors the only people = that can generate a valid, signed NSEC or NSEC3 RR? So if there were a = bad NSEC[3], wouldn't it be the ancestor's fault? If the provisioning is *intentional*, then as I noted before, then = there's not really anything to be done, since the ancestor can provide = whatever information he wants for the child zones (as above). So are = you worried about *inadvertent* provisioning of these bad records? =20 >> 5.10. =20 >> I find the recommendation of the "Accept Any Success" policy >> troubling. It deals very poorly with compromise (and other >> roll-over scenarios): Suppose there are two trust anchors, one for >> example.com and one for child.example.com. If the private key >> corresponding to the TA for child.example.com is compromised, but >> the validator continues to trust it, this negates the benefit >> provided by the parent (example.com) facilitating a rollover. >> Suggest an alternative policy, "Highest Signer": Out of the set of >> keys configured as TAs, the validator only uses a key as a TA (for >> purposes of validation) if there does not exist a DNSSEC path from >> it to any other TA. This policy seems like more work to enforce >> (because you have to do more backward chaining), but ISTM that the >> validator should have the necessary DNSSEC records anyway, so it's >> just a matter a couple of quick checks. >=20 > First, the Working Group debated this matter at considerable length, > several times. The Accept Any Success policy provides greater > robustness in the face of configuration errors, and is more likely to > lead to continued resolution. We believe, based on experience so far, > that such configuration errors are vastly more likely than key > compromise. If we are to reopen this, we will need to go back to the > WG again. =20 >=20 > Note that Appendix C does discuss other options and 5.10 explicitly > suggests that this be configurable; but, because the biggest problem > we have is resolution failure in the face of mucked up configurations, > the consensus was that Accept Any Success was the best default. That > could, of course, change in future, at which time an update to the > document would be advisable. >=20 > The suggestion for "Highest Signer" is interesting but has never to my > knowledge been previously mooted in relation to this draft. I > therefore think that including it in particular would require some > review. I don't know of any implementation that currently uses that > approach, either (but since there are vast gaps in my knowledge even > of what's on my desk, it wouldn't surprise me to learn that there were > some). Do you know of any? If not, it seems to me that it would be a > good idea to have some fielded experience with the approach before > recommending it as default. It's an intriguing idea, however, and > seems to me to be worth pursuing. I'm just not sure it should be in > this draft. I personally think it would be premature to recommend it > as default, but if you take your position very firmly I am prepared to > take the question up with the Working Group. Ok, I can understand these considerations. Typical usability/security = trade-off. As per the normal security MO, if you're going to recommend an approach = with known security weaknesses, then you need to document them. I think = it would be helpful to note how this approach can lead to problems, = e.g., by causing you to miss a roll-over of a compromised key. The = current text seems insufficient, especially because it's relegated to an = appendix. Suggested text at the end of Section 5.10: NEW: " This policy minimizes the likelihood that configuration errors in = servers or resolvers will result in validation failures. However, by = the same token, a resolver following this policy is vulnerable to a = broader set of attacks than one following a more restrictive policy. = For example, if the resolver has TAs for a parent domain and a child of = that parent, and the child's key is compromised, then the resolver will = continue to validate responses signed under the compromised key even if = a new key for the child is published in a DS record signed by the = parent. =20 " May also be helpful to say something like "as we get more experience = with validation, we may find that it's OK to be more restrictive". If you're willing to, it might be helpful to document the "Highest = signer" approach. If so, let me know and I can provide text. Thanks, --Richard =20 From davidb@verisign.com Mon Jul 30 13:31:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B195411E8163; Mon, 30 Jul 2012 13:31:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyVP6L9mU55i; Mon, 30 Jul 2012 13:31:13 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1701311E8133; Mon, 30 Jul 2012 13:31:01 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUBbvBS3GDgnPkJ9RoxJeKOZ64e2FUqVa@postini.com; Mon, 30 Jul 2012 13:31:12 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q6UKUobn024875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 16:30:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 30 Jul 2012 16:30:51 -0400 From: "Blacka, David" To: "Richard L. Barnes" Thread-Topic: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 Thread-Index: AQHNTcEBiArox8QTa0KZinofYFCgT5dCliyAgAA1yYA= Date: Mon, 30 Jul 2012 20:30:49 +0000 Message-ID: References: <20120619021211.GI32683@crankycanuck.ca> <9A7F5D7E-C3A8-4118-ADA1-C9CB814CDF72@bbn.com> In-Reply-To: <9A7F5D7E-C3A8-4118-ADA1-C9CB814CDF72@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <69AE58FA13615E4B8B754C07B1BF039F@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , IESG , "" , "" Subject: Re: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:31:13 -0000 On Jul 30, 2012, at 1:18 PM, Richard L. Barnes wrote: >>>=20 >>> MAJOR: >>>=20 >>> 4.1. =20 >>> It's not clear what the threat model is that this section is >>> designed to address. If the zone operator is malicious, then it can >>> simulate the necessary zone cut and still prove the non-existence of >>> records in the child zone. >>=20 >> The problem here is not a malicious parent operator, but "an NSEC or >> NSEC3 RR from an ancestor zone". In the original specification, an >> attacker could use such an RR to prove the non-existence of some name >> in a subordinate zone. That was the problem. (Remember, in DNS there >> is a good chance that you are not talking to an authoritative server.) >> If you have suggestions on ways to make that clearer, it'd be welcome. >> The editors tried to come up with compact examples that would be >> anything other than mystifying, and were unsuccessful. =20 >=20 > I guess I still don't understand this. Aren't ancestors the only people = that can generate a valid, signed NSEC or NSEC3 RR? So if there were a bad= NSEC[3], wouldn't it be the ancestor's fault? This isn't about "bad NSEC[3]" RRs. It is about an attacker (think "man-in= -the-middle") using the valid, completely correct NSEC[3] RR from the paren= t zone in an inappropriate context. > If the provisioning is *intentional*, then as I noted before, then there'= s not really anything to be done, since the ancestor can provide whatever i= nformation he wants for the child zones (as above). So are you worried abo= ut *inadvertent* provisioning of these bad records? =20 Again, the record isn't "bad", but being used in the wrong context (either = via a software bug or on purpose as an attack). This section isn't about m= alicious zone operators at all. I still don't have any great ideas for how to change the text to make this = more clear, however. -- David Blacka =20 Principal Verisign Infrastructure Engineering From ogud@ogud.com Tue Jul 31 18:54:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609FC11E81B0; Tue, 31 Jul 2012 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cxb3rb056SA; Tue, 31 Jul 2012 18:54:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2917D11E80DB; Tue, 31 Jul 2012 18:54:06 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q711s2B0065922; Tue, 31 Jul 2012 21:54:02 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <50188C37.8020909@ogud.com> Date: Tue, 31 Jul 2012 21:53:59 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: int-ads@tools.ietf.org, iesg-secretary@ietf.org Subject: [dnsext] Publication request: IANA Considerations X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:54:07 -0000 Ralph, DNSEXT has concluded its work on new DNS IANA Considerations replacing RFC6195 http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ Please start the publication process for it. thanks Olafur -- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? BCP Why is this the proper type of RFC? It specifies IANA Considerations for much of the DNS protocol and is obsoleting previous BCP RFC 6195. Is this type of RFC indicated in the title page header? Yes (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. Working Group Summary This document is to a large extent the same as its predecessor, but the working group has made some simplifications in process and these were not controversial. There is strong consensus behind this document. Document Quality There are many DNS implementations. This document is high quality due to reviews by a number of strong reviewers/experts including Alfred Hoenes and Mark Andrews. Personnel The document Shepherd is Olafur Gudmundsson ogud@ogud.com Ralph Droms is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has reviewed all changes in the document from predecessor and made sure there was consensus for the changes. The document is ready to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? None (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. It is a DNS document but, since it has been processed through the DNSEXT WG, DNS review has been sufficient. As this document is a successor to previous BCP with few changes prior reviews should be sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are normative references to (1) "Extension Mechanisms for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0, which is currently in IESG Consideration with one DISCUSS to clear, and (2) "Clarifications and Implementation Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates, which is currently in IESG Consideration with one DISCUSS to clear. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? It obsoletes RFC 6195 and updates four other DNS related RFCs. If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. All are listed in the abstract. Appendix B lists all changes from RFC 6195. Update to 1183 on AFSDB is the specification of AFSDB IANA considerations. Update to 2845 and 2930 is clarification that their "error" fields have values from the single unified DNS RCODE/error code point space. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The whole document is IANA considerations, replacing existing guidance for IANA on a set of registries created for use by the DNS protocol. There are no new registries, the document closes one registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are very simple regular expressions in Section 3.1 and 3.2 that were reviewed by the WG. Changes to these regular expressions were suggested that were discussed, some rejected and some adopted. In particular, a suggestion to prohibit hyphens was rejected and a suggestion to simplify the prohibitory part, which had been (CLASS|RRTYPE)(0|[1-9][0-9]*), was accepted.