From sm@resistor.net Tue Apr 2 21:35:56 2013 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 CE69C21F86CB for ; Tue, 2 Apr 2013 21:35: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=[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 oi+kFLSwDvSW for ; Tue, 2 Apr 2013 21:35:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E778C21F86CA for ; Tue, 2 Apr 2013 21:35:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r334ZoaQ005778 for ; Tue, 2 Apr 2013 21:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364963755; bh=FOoyxAP1HgOHHQoGY2Lc7vK3LOXbjeVetQ+NsDgBj7g=; h=Date:To:From:Subject:In-Reply-To:References; b=0Ra+3ePE6jcoLm6vtKcwDQRuqQHJKgcTQRpa83seXT62bWi2T54YY/te6YmSD8EmS MSu9jaC6fuT6AcUO7SRx0ULbfer7t8rjBH8DaN/quOj0JS0AxKfjrCWqEPFhgsx6j3 qV8GaDBWTkXLAkKxHCmTyP5+6siHefeRuaXEwHV4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364963755; i=@resistor.net; bh=FOoyxAP1HgOHHQoGY2Lc7vK3LOXbjeVetQ+NsDgBj7g=; h=Date:To:From:Subject:In-Reply-To:References; b=XkDuisjmlUIdMXIMbEwGBT4GYaSHl97pMNwFhbiK6PFnPk+j8Owjgb5Q4FPQAYlZ6 XnH4/S6dkzkZtym466anzKY+sf0zfVsD1so9dyBKYKRlLehw8EdlVVbvY0FeQB3Dvu 7rlfM3FD0PnRLVEQzxPlItWSNJwfBY2GBn1yHB0A= Message-Id: <6.2.5.6.2.20130331082930.0bb31c08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 Apr 2013 21:35:50 -0700 To: dnsext@ietf.org From: SM In-Reply-To: <20130320182712.16573.74697.idtracker@ietfa.amsl.com> References: <20130320182712.16573.74697.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] Last Call: (Signaling Cryptographic Algorithm Understanding in DNSSEC) 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: Wed, 03 Apr 2013 04:35:56 -0000 At 11:27 20-03-2013, The IESG wrote: >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2013-04-03. Exceptionally, comments may be In Section 4: "Intermediate proxies [RFC5625] that understand DNS are RECOMMENDED to behave like a comparable recursive resolver when dealing with the DAU, DHU and N3U options." I suggest referencing the appropriate section in the document to make this clear. Regards, -sm From scottr.nist@gmail.com Wed Apr 3 11:12:36 2013 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 6B33121F8C6F for ; Wed, 3 Apr 2013 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 gms3Z0e5vJkz for ; Wed, 3 Apr 2013 11:12:36 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2521F8D86 for ; Wed, 3 Apr 2013 11:12:35 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so2044478iej.16 for ; Wed, 03 Apr 2013 11:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jj7kGFmT4JbugY5QNQR4wAc39G2izBo+VXqUt0N1xtA=; b=RJQ0vh/S/yQrTCnJOV/vjD75AWl8nwFeY2pZYVD/eUUqhU9KReNAWDCGH2LpbqUk+b uLVrI+rGrohgVFAd9iZpBz/EIfInh/kgyFGGVTksAJzy5fw+ou2idFlEzs8OZVrHNecG GNMCDLC1XjSiA6HmNSJtd/doC5QtEpmCuLnVXpATpmC6ln2rzX8iuQqjkDQof9pAEH7B zYKKpPHGHKZ5vxUhSiQ4wlS+Ku+rsfPhBEQ+5LmWi0ZcbzC+UxaiPyw1zCTeiA72NDcD 4yubebg0R5ZF7A9xsNFwmKbsOfW4EObv35fZWd8GLHKa0N+/1SCZ9x5PwS6PTVUP4gYG ik+w== MIME-Version: 1.0 X-Received: by 10.50.50.71 with SMTP id a7mr7919532igo.14.1365012751492; Wed, 03 Apr 2013 11:12:31 -0700 (PDT) Received: by 10.50.79.234 with HTTP; Wed, 3 Apr 2013 11:12:31 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130331082930.0bb31c08@resistor.net> References: <20130320182712.16573.74697.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130331082930.0bb31c08@resistor.net> Date: Wed, 3 Apr 2013 14:12:31 -0400 Message-ID: From: Scott Rose To: SM Content-Type: multipart/alternative; boundary=089e013c5c442aaa0a04d978cc2e Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Signaling Cryptographic Algorithm Understanding in DNSSEC) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:12:36 -0000 --089e013c5c442aaa0a04d978cc2e Content-Type: text/plain; charset=ISO-8859-1 Ok - that's easy enough. It's in Sec. 4.4.2 (of RFC 5625). Scott On Wed, Apr 3, 2013 at 12:35 AM, SM wrote: > At 11:27 20-03-2013, The IESG wrote: > >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-04-03. Exceptionally, comments may be >> > > In Section 4: > > "Intermediate proxies [RFC5625] that understand DNS are RECOMMENDED to > behave like a comparable recursive resolver when dealing with the > DAU, DHU and N3U options." > > I suggest referencing the appropriate section in the document to make this > clear. > > Regards, > -sm > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > --089e013c5c442aaa0a04d978cc2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok - that's easy enough. =A0It's in Sec. 4.4.2 (of RFC 5625).
<= br>
Scott


On Wed, Ap= r 3, 2013 at 12:35 AM, SM <sm@resistor.net> wrote:
At 11:27 20-03-2013, The I= ESG wrote:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2013-04-03. Exceptionally, comments may be

In Section 4:

=A0"Intermediate proxies [RFC5625] that understand DNS are RECOMMENDED= to
=A0 behave like a comparable recursive resolver when dealing with the
=A0 DAU, DHU and N3U options."

I suggest referencing the appropriate section in the document to make this = clear.

Regards,
-sm
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--089e013c5c442aaa0a04d978cc2e-- From sm@resistor.net Wed Apr 3 23:00:49 2013 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 971A021F93D6 for ; Wed, 3 Apr 2013 23:00:49 -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 ReZceIMNrT4L for ; Wed, 3 Apr 2013 23:00:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9F21F93A3 for ; Wed, 3 Apr 2013 23:00:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3460dKA021757; Wed, 3 Apr 2013 23:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365055245; bh=GKmTQQHAP1zxpdTAqM4akop3NcUOffbDOxCEf0ufEbw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pzhOhE1UPW7bGM136y5/ds/qHF0ESZRS4toSPtMjgW86vZ9OqK/7W5S1CLHVEQT+w 9c7XDHpsH2Z4wKdd2kzvc1J8WTaS7rcWhdP4tjs6hnGFUEDxyzGAig5Uc9aSY+edE7 JRutf1MrAPcXxiZRCj2teR6PGB4FcvsFx5v6DI48= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1365055245; i=@resistor.net; bh=GKmTQQHAP1zxpdTAqM4akop3NcUOffbDOxCEf0ufEbw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mCYJ/AkZ80YBoJRSrh6KvaX8aRtjsjVIKZfaCX9FcSCpeYgn3CCoJrmKkBdXriMml azf62MzS26fwN4O2gngcKZ5CPdiWF6wFIlg+X0iM/F//5wQpH2grfCYcwwfsTsims+ 7v7c/7tkRP01Fnt37KEU28E4wMyFDVI/KjbashIc= Message-Id: <6.2.5.6.2.20130403225250.0c6a1a20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Apr 2013 23:00:29 -0700 To: scott.rose@nist.gov From: SM In-Reply-To: References: <20130320182712.16573.74697.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130331082930.0bb31c08@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Signaling Cryptographic Algorithm Understanding in DNSSEC) 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: Thu, 04 Apr 2013 06:00:49 -0000 Hi Scott, At 11:12 03-04-2013, Scott Rose wrote: >Ok - that's easy enough. It's in Sec. 4.4.2 (of RFC 5625). Thanks. The reference might reduce future discussions. :-) Regards, -sm From envite@rolamasao.org Sun Apr 7 05:53:42 2013 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 E6E1021F8D2D for ; Sun, 7 Apr 2013 05:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVHYZZFrQ4nF for ; Sun, 7 Apr 2013 05:53:42 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id A4B2921F8B08 for ; Sun, 7 Apr 2013 05:53:40 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 499BC11EAB for ; Sun, 7 Apr 2013 13:53:38 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Sun, 7 Apr 2013 13:53:31 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201303171259.07860.envite@rolamasao.org> <201303180041.38715.envite@rolamasao.org> <20130319035805.GA19020@vacation.karoshi.com.> In-Reply-To: <20130319035805.GA19020@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1454979.Y1eG8ogQQs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201304071353.33136.envite@rolamasao.org> Subject: Re: [dnsext] DNS-like system for OID [WAS: Presentation and question] 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, 07 Apr 2013 12:53:43 -0000 --nextPart1454979.Y1eG8ogQQs Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Martes, 19 de marzo de 2013 03:58:05 bmanning@vacation.karoshi.com wrote: > my my.. Steve Hotz and I did this 20 years ago - when the DNS was much > less ossified than it is today. we started w/ new class, ended up > anchoring in the int. tree (when we had emptied out arpa of everything but > in-addr.... but that is another story). >=20 > it didn't get much traction then, would be happy to work on it again. >=20 > /bill Skeleton would be like this: Rationale: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current DNS IN class schemene intends to trace between a tree-like structur= e=20 (the domain names, rooted at . ) and a linear structure (the IP addresses,= =20 between 0.0.0.0 and 2555.255.255.255 ) . It has been extended to include IP= v6=20 addresses, but these are a linear structure too (from :: to=20 =46FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ) . IN class also includes an inv= erse=20 resolution (from linear IP to tree-like Domain Names) which is a tweak whic= h=20 really resolves between IP-like Domain Names and real Domain Names and also= =20 does not address fully issues like IP delegation in non-8bit boundaries (Se= e=20 RFC 2317 ) . OID, instead, is a tree-like structure on its own, with (currently) three=20 roots (0, 1 and 2) which can be super-rooted at . so this "skeleton proposa= l"=20 intends to draw a way to map from tree-like structure to tree-like structur= e,=20 fully forward and backwards, including also extra information that may be=20 deemed useful. Also, this proposal allows OID owners to publicily state about canonical=20 hostnames where information about their OIDs (or the organizations holding= =20 them) can be found. 8<----------------------------------------------------------- This "skeleton proposal" uses class name OID throught it. Notes: =3D=3D=3D=3D=3D=3D Names and numbers are displayed from root to leaf, unlike in DNS IN class. Resource Record Types: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SOA: Similar to that of IN class, there will be two SOA registers to mainta= in,=20 one for number-name conversion and one for name-number. OID: Similar to A or AAAA of IN class, will be used only for name-number=20 conversion. NAME: Similar to PTR of IN class, will be used only for number-name=20 conversion. NS: Equivalent to that of IN class, will point to oid-capable nameservers=20 which hold thata for the current zone, being this either number->name or na= me- >number. DNS: Available in number->name zone only (they can be reached from a name i= f=20 you perform a name->number search first and an A search afterwards). They=20 point to the canonical IN DNS hostname for the OID, however it is defined b= y=20 OID owner. TXT: These are available in name->number zone only (they can be reached fro= m a=20 number if you perform a number->name search first and a TXT search=20 afterwards). They can include whichever information OID ownser deems=20 necessary, much like IN class TXT records. EQUIV: These are available in both zone types, and are similar to IN class= =20 CNAME. It indicates that all searches that may be conducted after one OID=20 number or name are to be conducted after another OID number or name instead= =2E=20 No mixture of numbers and names allowed. This RR specifically claims that=20 subtrees under the two OIDs are exactly equal. Example resource records: =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 ;-------------- ;NAME zone =2Eiso.identified-organization.dod.internet.private.enterprise.rolamasao-or= g OID=20 SOA (ns.rolamasao.org envite.rolamasao.org 2013040701 172800 86400 2419200= =20 604800) @ OID NS ns.rolamasao.org @ OID NS ns2.rolamasao.org @ OID TXT "Rolamasao.org related elements" @ OID OID .1.3.6.1.4.1.41434 persona OID OID 1 individual OID OID 2 individual OID EQUIV persona ;NUMBER zone =2E1.3.6.1.4.1.41434 OID SOA (ns.rolamasao.org envite.rolamasao.org 2013040= 701=20 172800 86400 2419200 604800) @ OID NS ns.rolamasao.org @ OID NS ns2.rolamasao.org @ OID NAME .iso.identified- organization.dod.internet.private.enterprise.rolamasao-org @ OID DNS www.rolamasao.org 1 OID NAME persona 2 OID NAME individual 2 OID EQUIV persona ;-------------- Recursive search: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Due to exact tree-to-tree mapping, and to avoid long strings like=20 ".iso.identified-organization.dod.internet.private.enterprise.rolamasao-org= "=20 it is allowed to make short references like these: INSTEAD OF @ OID OID .1.3.6.1.4.1.41434 IT IS ALLOWED @ OID OID 41434 INSTEAD OF @ OID NAME .iso.identified- organization.dod.internet.private.enterprise.rolamasao-org IT IS ALLOWED @ OID NAME rolamasao-org These not-starting-with-dot records will force recursive search. Root of the trees: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nominally the root of both trees will be . but all clients should know that= =20 the real roots are 0. 1. and 2. for numbers and itu-t. iso. and joint-iso-i= tu- t. for names. 8<----------------------------------------------------------- Please comment (yes, this is a request for comments but not a Request For=20 Comments yet). Noel Torres er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart1454979.Y1eG8ogQQs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlFhbE0ACgkQcLQA8+7Hw3L9vwCfXnow5bT4ywEbYAC3HxllqPof xdEAnRXoadSN5/aAwxvVMcAhfaN9WNuK =WP5I -----END PGP SIGNATURE----- --nextPart1454979.Y1eG8ogQQs-- From internet-drafts@ietf.org Mon Apr 8 08:54:49 2013 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 0CB6221F93E8; Mon, 8 Apr 2013 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, 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 vYJcBRtDedGS; Mon, 8 Apr 2013 08:54:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A2021F9157; Mon, 8 Apr 2013 08:54:48 -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.43.p3 Message-ID: <20130408155448.28695.71629.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 08:54:48 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-10.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, 08 Apr 2013 15:54:49 -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 : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-10.txt Pages : 9 Date : 2013-04-08 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The proposed extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC signed zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scottr.nist@gmail.com Mon Apr 8 09:01:24 2013 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 5B84821F97B2 for ; Mon, 8 Apr 2013 09:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.708, 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 BdV9Swi0nNAB for ; Mon, 8 Apr 2013 09:01:22 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6C17A21F97AF for ; Mon, 8 Apr 2013 09:01:22 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 8 Apr 2013 12:01:18 -0400 Received: from smtp.nist.gov (129.6.16.226) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server id 8.3.298.1; Mon, 8 Apr 2013 12:01:20 -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 r38G1JbF017411; Mon, 8 Apr 2013 12:01:19 -0400 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Scott Rose In-Reply-To: <20130408155448.28695.39174.idtracker@ietfa.amsl.com> Date: Mon, 8 Apr 2013 12:01:19 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <13CDF1EC-5402-4A44-8E92-D5A990BA15F2@gmail.com> References: <20130408155448.28695.39174.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1283) Cc: "dnsext-chairs@tools.ietf.org chair" , Ted Lemon Subject: Re: [dnsext] New Version Notification - draft-ietf-dnsext-dnssec-algo-signal-10.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, 08 Apr 2013 16:01:24 -0000 FYI, Changes include: 1. giving a section ref for Intermediate DNS entities (i.e. proxies, = etc.)=20 2. Added text to explicitly say that authoritative servers (and = recursive resolvers) MUST NOT set the algo-signal options in responses. = Likewise, clients MUST ignore the options if they see them in responses. 3. Authoritative servers (or any other stat gathering system) MAY ignore = any algo-signal option values that are out of range or RESERVED values. Scott On Apr 8, 2013, at 11:54 AM, internet-drafts@ietf.org wrote: >=20 > A new version (-10) has been submitted for = draft-ietf-dnsext-dnssec-algo-signal: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-1= 0.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-10= >=20 > IETF Secretariat. >=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 From joelja@bogus.com Sun Apr 14 08:56:05 2013 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 3920221F8B07 for ; Sun, 14 Apr 2013 08:56:05 -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 x9JwLLWQkUKe for ; Sun, 14 Apr 2013 08:56:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4455B21F85BF for ; Sun, 14 Apr 2013 08:56:04 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3EFtvem040691 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 14 Apr 2013 15:55:58 GMT (envelope-from joelja@bogus.com) Message-ID: <516AD188.1020408@bogus.com> Date: Sun, 14 Apr 2013 08:55:52 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: dnsext@ietf.org, dnsops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Apr 2013 15:56:00 +0000 (UTC) Cc: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org Subject: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 15:56:05 -0000 I've been asked to take this document on as AD sponsored individual submission. http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 If there's anyone who has strenuous objections to that, please let me know. joel From mstjohns@comcast.net Sun Apr 14 09:40:19 2013 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 EDDEA21F90F1 for ; Sun, 14 Apr 2013 09:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.739 X-Spam-Level: X-Spam-Status: No, score=-99.739 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 qhXs55YsoseK for ; Sun, 14 Apr 2013 09:40:19 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7721F90DF for ; Sun, 14 Apr 2013 09:40:19 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id PsQc1l0031ZXKqc5CsgJXz; Sun, 14 Apr 2013 16:40:18 +0000 Received: from [192.168.1.106] ([68.83.212.126]) by omta21.westchester.pa.mail.comcast.net with comcast id Psg91l00w2kB7pQ3hsgAn7; Sun, 14 Apr 2013 16:40:18 +0000 References: <516AD188.1020408@bogus.com> Mime-Version: 1.0 (1.0) In-Reply-To: <516AD188.1020408@bogus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> X-Mailer: iPad Mail (10A550) From: Michael StJohns Date: Sun, 14 Apr 2013 12:40:09 -0400 To: joel jaeggli DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365957618; bh=dBeGBhttcLgs2++Mc1ZMylFIYb55l3SiKKmpM+gKkrY=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=B6AJkTGno6m7nEZxg7YfwQEPSgGISu/aLvkyrudjlm1o5PKppHrTlFnsro+WqZfgW w6vayDCRW0eF6+50Z6MYXRy5cM2gkkekvsTeoycQiVCcQyp6/HKl5y1xWStCYtC5TT UmN3M2RqRh7j7Yo3dVqgHo+LfZRX8QtnteXa5HndEtU1bAXLDPGwbU4iPWx40/pdM/ nTSgFx1/B/d5ADwZjd6HcGbept8XQ8upDtfjptZJH7LIQg1fIoSIwFDm7dNZAaSNLP ahpRvTVIDDjpvXG/EI/wnOb6FCOmJ790siIefBoSIYAfsQ8T0TbdDDGVB2Y5PTYFB1 SNC24gGheRFFQ== Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 16:40:20 -0000 What exactly is the purpose for this document? Specifically, please describ= e the concept of operations for the use of this record. Mapping a name directly to a MAC address seems somewhat problematic and perh= aps even dangerous to consistency.=20 I understand storing things in the DNS system is attractive, but adapting it= to store L2 data may be going a bit too far past it's designed scope, I would object to the document absent a clear and convincing description of w= hy it is needed and what applications will use it. =20 Mike Sent from my iPad On Apr 14, 2013, at 11:55, joel jaeggli wrote: > I've been asked to take this document on as AD sponsored individual submis= sion. >=20 > http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 >=20 > If there's anyone who has strenuous objections to that, please let me know= . >=20 > joel > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From paul.hoffman@vpnc.org Sun Apr 14 11:13:22 2013 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 2609321F90DF for ; Sun, 14 Apr 2013 11:13:22 -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 EiIphZTAzWqP for ; Sun, 14 Apr 2013 11:13: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 4F20321F8F44 for ; Sun, 14 Apr 2013 11:13:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3EID3nt081478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Apr 2013 11:13:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> Date: Sun, 14 Apr 2013 11:13:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> To: Michael StJohns X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 18:13:22 -0000 On Apr 14, 2013, at 9:40 AM, Michael StJohns = wrote: > I would object to the document absent a clear and convincing = description of why it is needed and what applications will use it. =20 Is such an objection really appropriate? I don't see anything in RFC = 6195 that would allow someone to demand a "clear and convincing = description of why it is needed and what applications will use it" = before an Internet Draft could even go to IETF Last Call, or even during = IETF Last Call to prevent registration of the RRTtypes requested (which = is all this Internet Draft is about). --Paul Hoffman= From mstjohns@comcast.net Sun Apr 14 11:17:07 2013 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 1246421F914C for ; Sun, 14 Apr 2013 11:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.506 X-Spam-Level: X-Spam-Status: No, score=-99.506 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 8yDfdlb8sSCm for ; Sun, 14 Apr 2013 11:17:06 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAF321F9138 for ; Sun, 14 Apr 2013 11:17:06 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id Ps4R1l0021GhbT85DuH5Sm; Sun, 14 Apr 2013 18:17:05 +0000 Received: from [192.168.1.106] ([68.83.212.126]) by omta07.westchester.pa.mail.comcast.net with comcast id PuH41l0152kB7pQ3TuH5VM; Sun, 14 Apr 2013 18:17:05 +0000 References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A550) From: Michael StJohns Date: Sun, 14 Apr 2013 14:17:05 -0400 To: Paul Hoffman DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365963425; bh=Ab+lq+yzk/Vmx8XIVaMsY2o0UbzaNFOeVne1EgfrS9Q=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=d6Ua3yJvjssw900Q3dj0P1emz/jW2D0PC7W5UJ9kxEEHuIzrdYSwVQA9BSIux6YHK pWjQlCBDnA/mj4FlcKO2ofqQekmNJcUwmCFN4/24e2enzYzrkBTla9vY8siWU+X0oc p9z39+y2v/QOEBQgNkJPwVVvJoXAirGlCgshVWrMxHY3zCtodisJaHqnB2nQuDg+5w YZrWiWyIRKIwYqukxRSfFx+N0xAf7yDT7RmeAWxvi88KRGOmR5VmxgwanVeWjaMBYG e66Guk9pnlWtTe473L04SZtVRzipliO2KaCQfInuLfh48Ilzq/BXbOMOXTRxSTg4SB 5wDkSG2HxwekQ== Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 18:17:07 -0000 Rfc6195, section 3.1.2, items 1, 4, and 5 apply. =20 Sent from my iPad On Apr 14, 2013, at 14:13, Paul Hoffman wrote: > On Apr 14, 2013, at 9:40 AM, Michael StJohns wrote:= >=20 >> I would object to the document absent a clear and convincing description o= f why it is needed and what applications will use it. =20 >=20 > Is such an objection really appropriate? I don't see anything in RFC 6195 t= hat would allow someone to demand a "clear and convincing description of why= it is needed and what applications will use it" before an Internet Draft co= uld even go to IETF Last Call, or even during IETF Last Call to prevent regi= stration of the RRTtypes requested (which is all this Internet Draft is abou= t). >=20 > --Paul Hoffman From paul.hoffman@vpnc.org Sun Apr 14 11:28:11 2013 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 D13F621F90DF for ; Sun, 14 Apr 2013 11:28:11 -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 n-sDY3WlolXi for ; Sun, 14 Apr 2013 11:28: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 753A421F90A1 for ; Sun, 14 Apr 2013 11:28:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3EIS7pq081803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Apr 2013 11:28:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Sun, 14 Apr 2013 11:28:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A0FB4D7-A1B3-47B4-9476-23E81652201B@vpnc.org> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> To: Michael StJohns X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 18:28:11 -0000 On Apr 14, 2013, at 11:17 AM, Michael StJohns = wrote: > Rfc6195, section 3.1.2, items 1, 4, and 5 apply. =20 To a request for an AD to bring the document to IETF Last Call? Where in = RFC 6195 do you see that? Or did you misunderstand Joel's question? --Paul Hoffman= From mstjohns@comcast.net Sun Apr 14 12:22:11 2013 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 608C121F8C4F for ; Sun, 14 Apr 2013 12:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.088 X-Spam-Level: X-Spam-Status: No, score=-100.088 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 zvj+6JBQDZ3Q for ; Sun, 14 Apr 2013 12:22:10 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6632621F84E3 for ; Sun, 14 Apr 2013 12:22:10 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id PuuQ1l0060xGWP85FvN9pX; Sun, 14 Apr 2013 19:22:09 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta12.westchester.pa.mail.comcast.net with comcast id PvN81l00k2kB7pQ3YvN9yL; Sun, 14 Apr 2013 19:22:09 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Apr 2013 15:22:08 -0400 To: Paul Hoffman From: Michael StJohns In-Reply-To: <7A0FB4D7-A1B3-47B4-9476-23E81652201B@vpnc.org> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> <7A0FB4D7-A1B3-47B4-9476-23E81652201B@vpnc.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_318740774==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365967329; bh=UObsWwCRfz1vhu3LqpsxLtq0C9GoShkxANwkTip0m10=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=l/lGbm/Lbhk1ATtR6DwI55SXj6xwgKTGmDj6a5OFPFSKU4g8TxYhR+eBVN4iCbjAf Ydxdn2+2VW/klov/wkqp4xGtT+Rkbu4SBKcP9LYqqe4UT2T0rnRORfvlHDjW+smfae agyMp4pt60TjPZSMMGRfqldK0PJE4BmomPwF168UTnJQVUg/VdbX9a6BaIoSgxVY20 8IQhse0roMxRtSDiLekuDC1MCNc/E38hfpYaOEBDs/R8QCD/L6cRhlm42ZvvppdQLg 7c9M2m3JdsfyX6TfT+xeODDF4Q6eGu1ujeVfyyDlg5bvcIqcLt2+2d5Cl2BabznxRu Al1y+c1BCb05Q== Message-Id: <20130414192210.6632621F84E3@ietfa.amsl.com> Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 19:22:11 -0000 --=====================_318740774==.ALT Content-Type: text/plain; charset="us-ascii" Let's try this again. I understood what Joel was asking. I objected to bringing this to last call. You asked where in RFC6195 that there was grounds to object. I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the following: Although the allocation template says that the code points were assigned by expert review, its unclear they followed the criteria required by 6145. Given the lack of details, I don't see how an expert could say: (1) that the documentation was complete enough to evaluate. (4) that the document was complete enough to describe any other interactions with DNS - for example publishing the DNS name to IP mapping as part of a DHCP IP address assignment process for the MAC address. and (5) that give the lack of 1 and 4, and the short shrift to "well, we could do it in the text record, but we'd rather not" that it's unclear why this is a global assignment rather than a private one. If this makes it through in the current condition, I would suggest that I could submit a document based on the current document where EUi48 is changed to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes" with fairly minimal text changes that would ALSO make it through. And that would be bad. Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the 6145 mandated application and experts assignment message on the list or in the archives: >After the applicant posts their formal application with their > template as specified in Appendix A, IANA appoints an Expert and the > template is posted, with an indication that it is a formal > application, to the dnsext@ietf.org mailing list. No less than three > weeks and no more than six weeks after this posting to > dnsext@ietf.org, the selected Expert shall post a message, explicitly > accepting or rejecting the application, to IANA, dnsext@ietf.org, and > the email address provided by the applicant. If the Expert does not > post such a message, the application shall be considered rejected but > may be resubmitted to IANA. IANA should report non-responsive > Experts to the IESG. Mike At 02:28 PM 4/14/2013, Paul Hoffman wrote: >On Apr 14, 2013, at 11:17 AM, Michael StJohns wrote: > >> Rfc6195, section 3.1.2, items 1, 4, and 5 apply. > >To a request for an AD to bring the document to IETF Last Call? Where in RFC 6195 do you see that? Or did you misunderstand Joel's question? > >--Paul Hoffman --=====================_318740774==.ALT Content-Type: text/html; charset="us-ascii" Let's try this again.

I understood what Joel was asking.  I objected to bringing this to last call.

You asked where in RFC6195 that there was grounds to object.

I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the following:


Although the allocation template says that the code points were assigned by expert review, its unclear they followed the criteria required by 6145.  Given the lack of details, I don't see how an expert could say:

(1) that the documentation was complete enough to evaluate.

(4) that the document was complete enough to describe any other interactions with DNS - for example publishing the DNS name to IP mapping as part of a DHCP IP address assignment process for the MAC address.

and (5) that give the lack of 1 and 4, and the short shrift to "well, we could do it in the text record, but we'd rather not" that it's unclear why this is a global assignment rather than a private one.


If this makes it through in the current condition, I would suggest that I could submit a document based on the current document where EUi48 is changed to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes" with fairly minimal text changes that would ALSO make it through.  And that would be bad.


Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the 6145 mandated application and experts assignment message on the list or in the archives:


After the applicant posts
their formal application with their
   template as specified in
Appendix A,
IANA appoints an Expert and the
   template is posted, with an indication that it is a formal
   application, to the dnsext@ietf.org mailing list.  No
less than three
   weeks and no more than six weeks after this posting to
   dnsext@ietf.org, the selected Expert shall post a message,
explicitly
   accepting or rejecting the application, to IANA,
dnsext@ietf.org, and
   the email address provided by the applicant.  If the
Expert does not
   post such a message, the application shall be considered
rejected but
   may be resubmitted to IANA.  IANA should report
non-responsive
   Experts to the
IESG.



Mike


At 02:28 PM 4/14/2013, Paul Hoffman wrote:
On Apr 14, 2013, at 11:17 AM, Michael StJohns <mstjohns@comcast.net> wrote:

> Rfc6195, section 3.1.2, items 1, 4, and 5 apply.  

To a request for an AD to bring the document to IETF Last Call? Where in RFC 6195 do you see that? Or did you misunderstand Joel's question?

--Paul Hoffman

--=====================_318740774==.ALT-- From d3e3e3@gmail.com Sun Apr 14 14:38:35 2013 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 C756E21F9183 for ; Sun, 14 Apr 2013 14:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 fBvUGlAPy6fI for ; Sun, 14 Apr 2013 14:38:34 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5A21F913C for ; Sun, 14 Apr 2013 14:38:34 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id f4so3877265oah.28 for ; Sun, 14 Apr 2013 14:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:cc:content-type; bh=PAN+m0gZBHZQ42uxQvZRv3ksBpzjWBbYv2v9OPe7ELs=; b=kgjxWiVM4XlVgPKGmLBjCh3yhzpMIAdOsRIWMwFZxehP1WdnOaODAjw8QPts/dFT2+ EJ83A1rJQj4WMSuioHBLYpQEL7WEUAV8xRu0huZBMHjwXiamh46DYpf1Lbi3fIrN12ye IwuU1WzzZ+B7gUOVCB+9lMIbvYlU9F4wVmYgmTIip6fDsnVPxfmKzh8MD/8yvdNCBBqy Jwxfcqe/1Ujj832plnTWPGdrKQCRkicP1PZA0tHXSUEsPFBkFcDluMSYfg4dllMPgzUb lEvsY6zukO9IqPW+qXn5bj2rN5k4Fs/WDUTzwHLOKwXUSENycwOii+AL78WeWV1Onx+/ SyIw== X-Received: by 10.60.132.196 with SMTP id ow4mt5476338oeb.75.1365975513741; Sun, 14 Apr 2013 14:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Sun, 14 Apr 2013 14:38:13 -0700 (PDT) In-Reply-To: <20130414192210.6632621F84E3@ietfa.amsl.com> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> <7A0FB4D7-A1B3-47B4-9476-23E81652201B@vpnc.org> <20130414192210.6632621F84E3@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 14 Apr 2013 17:38:13 -0400 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 21:38:35 -0000 RFC 6195 is not in effect. draft-ietf-dnsext-rfc6195bis-05 (RFC-to-be 6895) is in effect since it was approved last year. It's been held up by a dependency but will presumably will pop out early next week since it looks like the dependency has cleared. On Sun, Apr 14, 2013 at 3:22 PM, Michael StJohns wrote: > Let's try this again. > > I understood what Joel was asking. I objected to bringing this to last > call. As below, if the last call is blocked it might block documentation and review but will have no effect on the code points. > You asked where in RFC6195 that there was grounds to object. > > I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the > following: > > Although the allocation template says that the code points were assigned by > expert review, its unclear they followed the criteria required by 6145. They are not "criteria required". They are *guidelines* and the overall policy, from RFC-to-be-6895 is "The Designated Expert should normally be lenient, preferring to approve most requests." > Given the lack of details, I don't see how an expert could say: > > (1) that the documentation was complete enough to evaluate. > > (4) that the document was complete enough to describe any other interactions > with DNS - for example publishing the DNS name to IP mapping as part of a > DHCP IP address assignment process for the MAC address. > > and (5) that give the lack of 1 and 4, and the short shrift to "well, we > could do it in the text record, but we'd rather not" that it's unclear why > this is a global assignment rather than a private one. As regards the allocation of the code points, it actually does not make any difference what you think. The application was submitted. The assigned expert has approved. (I am not a member of the expert pool.) The code points (108 and 109) have been allocated and are in the public RRTYPE registry as of, probably, a couple of week ago, and since then anyone in the world has been free to use them: http://www.iana.org/assignments/dns-parameters/dns-parameters.xml > If this makes it through in the current condition, I would suggest that I > could submit a document based on the current document where EUi48 is changed > to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes" > with fairly minimal text changes that would ALSO make it through. And that > would be bad. It seems odd to restrict it breakfast cereal UPC codes, but having an DNS RRTYPE for UPC code or ISBN number seems fine to me. Why would it be bad to store such things in the DNS? It would provide a way to securely associate such numbers with a DNS name. > Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the > 6145 mandated application and experts assignment message on the list or in > the archives: See RFC-to-be-6895. Such a message has not been required since the approval of RFC-to-be-6895 which is the result of years of effort to defeat narrow-minded objections and real and perceived barriers to getting new RRtypes for ordinary data (can be handled as an Unknown RR as described in [RFC3597]). In my opinion, there is almost never a reason to turn down such an RRTYPE request and the rapid approval of this request is exactly what is supposed to happen. I would like to thank the author for taking the step of proposing publication of his draft as an RFC, something not required. This provides an opportunity for review and, for example, possible inclusion of usage guidance or the like. Experience proves that the "you can't get a number without jumping through hoops" mindset leads to lots of overloadings of TXT and people just grabbing a random RRTYPE number and camping on it, which I think is a worse than, say, allocating some RRTYPE numbers for some data which turns out to be not so useful in the DNS. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > After the applicant posts > their formal application with their > template as specified in > Appendix A, > IANA appoints an Expert and the > template is posted, with an indication that it is a formal > application, to the dnsext@ietf.org mailing list. No > less than three > weeks and no more than six weeks after this posting to > dnsext@ietf.org, the selected Expert shall post a message, > explicitly > accepting or rejecting the application, to IANA, > dnsext@ietf.org, and > the email address provided by the applicant. If the > Expert does not > post such a message, the application shall be considered > rejected but > may be resubmitted to IANA. IANA should report > non-responsive > Experts to the > IESG. > > > > > Mike > > > > At 02:28 PM 4/14/2013, Paul Hoffman wrote: > > On Apr 14, 2013, at 11:17 AM, Michael StJohns wrote: > >> Rfc6195, section 3.1.2, items 1, 4, and 5 apply. > > To a request for an AD to bring the document to IETF Last Call? Where in RFC > 6195 do you see that? Or did you misunderstand Joel's question? > > --Paul Hoffman > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From mstjohns@comcast.net Sun Apr 14 15:45:40 2013 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 3DE1721F8C69 for ; Sun, 14 Apr 2013 15:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.157 X-Spam-Level: X-Spam-Status: No, score=-100.157 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 R9dV+jlS51wJ for ; Sun, 14 Apr 2013 15:45:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CD72321F8C55 for ; Sun, 14 Apr 2013 15:45:37 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id PxYM1l0050mv7h053ylYXf; Sun, 14 Apr 2013 22:45:32 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta11.westchester.pa.mail.comcast.net with comcast id PylX1l00c2kB7pQ3XylXF6; Sun, 14 Apr 2013 22:45:32 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Apr 2013 18:45:31 -0400 To: Donald Eastlake From: Michael StJohns In-Reply-To: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <531B3773-1D2E-4AAB-A8E7-94DD01DFE5B6@vpnc.org> <7A0FB4D7-A1B3-47B4-9476-23E81652201B@vpnc.org> <20130414192210.6632621F84E3@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_330943703==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365979532; bh=aJUEC8LvR+v0o6izvaY7a1Wf7fPLqzo3gEvd8d88lbo=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=KMp2lMH/ojZayaYufUP4VCoDM/z8p9czs+aRa9Xk3+r1nNWoDFD8ITaIuK/1toFBe F7hbD0rjcbpvdIxFOOMNAI03T3CejKB3OK74WY8BUHVFQJYQv8Bioqo7j2DQyCmeru LJcH0QbUYXufsZ6wf4QMWlPiupjLgrpHe/Zm08aeVy9ZuAXndH4/Loz8x607Aoi3oI C7InyTPFAqQmZOvk+npVwy/ZlNsVbmtx/E9sAbj7XnCao1r3FzqqUbiYmnMVGd/T+5 Vf6XlYhYuRvVr7dLtETdgqshxfxDWsBLn0hFQs8cK+Po0i6Ih+48iOD1CaEEawDrMT iGXMD38zhJQCA== Message-Id: <20130414224537.CD72321F8C55@ietfa.amsl.com> Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 22:45:40 -0000 --=====================_330943703==.ALT Content-Type: text/plain; charset="us-ascii" At 05:38 PM 4/14/2013, Donald Eastlake wrote: >RFC 6195 is not in effect. draft-ietf-dnsext-rfc6195bis-05 (RFC-to-be >6895) is in effect since it was approved last year. It's been held up >by a dependency but will presumably will pop out early next week since >it looks like the dependency has cleared. OK. Sort of double secret probation. I missed that announcement. >On Sun, Apr 14, 2013 at 3:22 PM, Michael StJohns wrote: >> Let's try this again. >> >> I understood what Joel was asking. I objected to bringing this to last >> call. > >As below, if the last call is blocked it might block documentation and >review but will have no effect on the code points. > >> You asked where in RFC6195 that there was grounds to object. >> >> I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the >> following: >> >> Although the allocation template says that the code points were assigned by >> expert review, its unclear they followed the criteria required by 6145. > >They are not "criteria required". They are *guidelines* and the >overall policy, from RFC-to-be-6895 is "The Designated Expert should >normally be lenient, preferring to approve most requests." "However, the Expert should usually reject any RRTYPE allocation request that meets one or more of the following criteria:" is what follows the above. I'd suggest that "SHOULD" here [my caps] sets the following items as criteria for evaluation, not guidelines. The word "usually" muddies the water so maybe you could get by with calling them guidelines. It's splitting hairs in any case. >> Given the lack of details, I don't see how an expert could say: >> >> (1) that the documentation was complete enough to evaluate. >> >> (4) that the document was complete enough to describe any other interactions >> with DNS - for example publishing the DNS name to IP mapping as part of a >> DHCP IP address assignment process for the MAC address. >> >> and (5) that give the lack of 1 and 4, and the short shrift to "well, we >> could do it in the text record, but we'd rather not" that it's unclear why >> this is a global assignment rather than a private one. > >As regards the allocation of the code points, it actually does not >make any difference what you think. The application was submitted. The >assigned expert has approved. (I am not a member of the expert pool.) >The code points (108 and 109) have been allocated and are in the >public RRTYPE registry as of, probably, a couple of week ago, and >since then anyone in the world has been free to use them: > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml > >> If this makes it through in the current condition, I would suggest that I >> could submit a document based on the current document where EUi48 is changed >> to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes" >> with fairly minimal text changes that would ALSO make it through. And that >> would be bad. > >It seems odd to restrict it breakfast cereal UPC codes, but having an >DNS RRTYPE for UPC code or ISBN number seems fine to me. Why would it >be bad to store such things in the DNS? It would provide a way to >securely associate such numbers with a DNS name. I used "breakfast cereal UPC codes" to describe an absurd case, but one that appears would be permitted without much review using pretty much the same boiler plate as the current document. It would be really nice if there were actually a real-world reason to have such a mapping though before doing such an assignment. I keep hoping for some sanity in DNS use, but it seems to be getting further and further distant. But getting back to the current case - 1) If you query the DNS for both an IP and a MAC address, and you get records for both, but the records don't point to the same physical host, what should you do, and how might you detect this? 2) If you query the DNS for MAC address records and you get multiple records for the same DNS name, what does that mean? 3) If you query the DNS for an IP and MAC address and only get a MAC address record, what does that mean? 4) If you query the DNS for an IP and a MAC, and then ARP for the MAC address and get a different value than the MACs from the DNS, what does that mean? At least in the UPC and ISBN stuff I can mostly assume they don't refer to an internet connected device. In the specific case, because the MAC address usually has some interaction with the IP address, and someone is bound to try and come up an application (e.g something besides ARP or DHCP) that cares about both simultaneously, it would REALLY be nice if the document at least set out the thoughts for why adding this type was a good idea, and possibly how to deal with some of the above issues. >> Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the >> 6145 mandated application and experts assignment message on the list or in >> the archives: > >See RFC-to-be-6895. Such a message has not been required since the >approval of RFC-to-be-6895 which is the result of years of effort to >defeat narrow-minded objections and real and perceived barriers to >getting new RRtypes for ordinary data (can be handled as an Unknown RR >as described in [RFC3597]). Umm.. I realize you wrote the draft, but I'm surprised you forgot what it said: >IANA appoints an Expert > and sends the completed template to the Expert copying the applicant. > No more than two weeks after receiving the application the Expert > shall explicitly approve or reject the application, informing IANA, > the applicant, and the dnsext@ietf.org mailing list. You took out the requirement to publish the application for comments, but you did not take out the requirement to publish the approval. I may have missed it, but I didn't see such a message from the assigned expert. >In my opinion, there is almost never a >reason to turn down such an RRTYPE request and the rapid approval of >this request is exactly what is supposed to happen. > >I would like to thank the author for taking the step of proposing >publication of his draft as an RFC, something not required. This >provides an opportunity for review and, for example, possible >inclusion of usage guidance or the like. > >Experience proves that the "you can't get a number without jumping >through hoops" mindset leads to lots of overloadings of TXT and people >just grabbing a random RRTYPE number and camping on it, which I think >is a worse than, say, allocating some RRTYPE numbers for some data >which turns out to be not so useful in the DNS. > >Thanks, >Donald >============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com --=====================_330943703==.ALT Content-Type: text/html; charset="us-ascii" At 05:38 PM 4/14/2013, Donald Eastlake wrote:
RFC 6195 is not in effect. draft-ietf-dnsext-rfc6195bis-05 (RFC-to-be
6895) is in effect since it was approved last year. It's been held up
by a dependency but will presumably will pop out early next week since
it looks like the dependency has cleared.


OK.  Sort of double secret probation.  I missed that announcement.


On Sun, Apr 14, 2013 at 3:22 PM, Michael StJohns <mstjohns@comcast.net> wrote:
> Let's try this again.
>
> I understood what Joel was asking.  I objected to bringing this to last
> call.

As below, if the last call is blocked it might block documentation and
review but will have no effect on the code points.

> You asked where in RFC6195 that there was grounds to object.
>
> I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the
> following:
>
> Although the allocation template says that the code points were assigned by
> expert review, its unclear they followed the criteria required by 6145.

They are not "criteria required". They are *guidelines* and the
overall policy, from RFC-to-be-6895 is "The Designated Expert should
normally be lenient, preferring to approve most requests."


"However, the Expert should usually reject any
   RRTYPE allocation request that meets one or more of the
following
   criteria:"
is what follows the above.  I'd suggest that "SHOULD" here [my caps] sets the following items as criteria for evaluation, not guidelines.  The word "usually" muddies the water so maybe you could get by with calling them guidelines.  It's  splitting hairs in any case.






> Given the lack of details, I don't see how an expert could say:
>
> (1) that the documentation was complete enough to evaluate.
>
> (4) that the document was complete enough to describe any other interactions
> with DNS - for example publishing the DNS name to IP mapping as part of a
> DHCP IP address assignment process for the MAC address.
>
> and (5) that give the lack of 1 and 4, and the short shrift to "well, we
> could do it in the text record, but we'd rather not" that it's unclear why
> this is a global assignment rather than a private one.

As regards the allocation of the code points, it actually does not
make any difference what you think. The application was submitted. The
assigned expert has approved. (I am not a member of the expert pool.)
The code points (108 and 109) have been allocated and are in the
public RRTYPE registry as of, probably, a couple of week ago, and
since then anyone in the world has been free to use them:
   http://www.iana.org/assignments/dns-parameters/dns-parameters.xml

> If this makes it through in the current condition, I would suggest that I
> could submit a document based on the current document where EUi48 is changed
> to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes"
> with fairly minimal text changes that would ALSO make it through.  And that
> would be bad.

It seems odd to restrict it breakfast cereal UPC codes, but having an
DNS RRTYPE for UPC code or ISBN number seems fine to me. Why would it
be bad to store such things in the DNS? It would provide a way to
securely associate such numbers with a DNS name.

I used "breakfast cereal UPC codes" to describe an absurd case, but one that appears would be permitted without much review using pretty much the same boiler plate as the current document.

It would be really nice if there were actually a real-world reason to have such a mapping though before doing such an assignment.  I keep hoping for some sanity in DNS use, but it seems to be getting further and further distant.

But getting back to the current case -

1) If you query the DNS for both an IP and a MAC address, and you get records for both, but the records don't point to the same physical host, what should you do, and how might you detect this?

2) If you query the DNS for MAC address records and you get multiple records for the same DNS name, what does that mean?

3) If you query the DNS for an IP and MAC address and only get a MAC address record, what does that mean?

4) If you query the DNS for an IP and a MAC, and then ARP for the MAC address and get a different value than the MACs from the DNS, what does that mean?



At least in the UPC and ISBN stuff I can mostly assume they don't refer to an internet connected device.  In the specific case, because the MAC address usually has some interaction with the IP address, and someone is bound to try and come up an application (e.g something besides ARP or DHCP) that cares about both simultaneously, it would REALLY be nice if the document at least set out the thoughts for why adding this type was a good idea, and possibly how to deal with some of the above issues.




> Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the
> 6145 mandated application and experts assignment message on the list or in
> the archives:

See RFC-to-be-6895. Such a message has not been required since the
approval of RFC-to-be-6895 which is the result of years of effort to
defeat narrow-minded objections and real and perceived barriers to
getting new RRtypes for ordinary data (can be handled as an Unknown RR
as described in [RFC3597]).


Umm.. I realize you wrote the draft, but I'm surprised you forgot what it said:


IANA appoints an Expert
   and sends the completed template to the Expert copying the
applicant.
   No more than two weeks after receiving the application the
Expert
   shall explicitly approve or reject the application,
informing IANA,
   the applicant, and the dnsext@ietf.org mailing
list.


You took out the requirement to publish the application for comments, but you did not take out the requirement to publish the approval.    I may have missed it, but I didn't see such a message from the assigned expert.

In my opinion, there is almost never a
reason to turn down such an RRTYPE request and the rapid approval of
this request is exactly what is supposed to happen.

I would like to thank the author for taking the step of proposing
publication of his draft as an RFC, something not required. This
provides an opportunity for review and, for example, possible
inclusion of usage guidance or the like.

Experience proves that the "you can't get a number without jumping
through hoops" mindset leads to lots of overloadings of TXT and people
just grabbing a random RRTYPE number and camping on it, which I think
is a worse than, say, allocating some RRTYPE numbers for some data
which turns out to be not so useful in the DNS.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

--=====================_330943703==.ALT-- From jabley@hopcount.ca Sun Apr 14 15:56:49 2013 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 8ED3421F8FFB for ; Sun, 14 Apr 2013 15:56:49 -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 IFJmr89RtStK for ; Sun, 14 Apr 2013 15:56:48 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9402821F8FDA for ; Sun, 14 Apr 2013 15:56:48 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so4736135iec.14 for ; Sun, 14 Apr 2013 15:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=wu1xJGd5pKNz4RzWkPA5maJ3WUHGKv4kC9QJ3+f6ScM=; b=S6m/zDQpVru35L2lXorbCv0hnp89dL6ewB5JZNmyHL8+6dQ6mczGDnUdEYoVEEOAUp OvqswH3Jzi3FdO07RjVCss0SydTuqZUXP+/WdgXEiZ049fTIOzKjeHgy43IRQlfL5xrX ZQxCYuNkgkMX59gwzvSy4C3FNfaZwDkHns9do= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=wu1xJGd5pKNz4RzWkPA5maJ3WUHGKv4kC9QJ3+f6ScM=; b=TF4nXq72sdwe6tjtODuPwPsd5l0CrU7eRs1bZ57xkznh45AIrblN3DHLFnJs0GWEcO BOoK+AsXBAlkv79LiKOn1U9HwB4nVXzz+/zNBRWRwnKQj4dT0sodJQ8OO4BvElJ5g9tw QYDNi3Q99HYvQqb8jWEhZNuRGml7t1fTTDcddes5rXP0iwGoP5cG7ztIutu5hHUbeZIs bkoJtxVk+JtndjjycFwJZcrqaapr7+L5SJm5rWTAnx5569qjJ1gOfShlSV0Vq8x9uM39 i1CpN6D7bNsA/GhGjNvDKm5rLZQEXDb72F53LyAnlupKcfKB3V8RYqEuFI39IkScwZ7k Bzuw== X-Received: by 10.50.208.40 with SMTP id mb8mr3773005igc.91.1365980208076; Sun, 14 Apr 2013 15:56:48 -0700 (PDT) Received: from tekmobile17.teksavvy.web (nat.teksavvy.com. [206.248.154.94]) by mx.google.com with ESMTPS id c14sm9554041ign.2.2013.04.14.15.56.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 15:56:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> Date: Sun, 14 Apr 2013 18:56:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> To: Michael StJohns X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkvP3TtSsOYKDW90IOBaClrX68U7XNGdS96CUNDDPrfS4BeQO6oXzSnEoo+8lq4BWRpKHWi Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 14 Apr 2013 22:56:49 -0000 Hi there, On 2013-04-14, at 12:40, Michael StJohns wrote: > What exactly is the purpose for this document? Specifically, please = describe the concept of operations for the use of this record. Regardless of whether it's required or not, there's no secret here and I = believe I've mentioned the motivations more than once on this list. Some cable internet companies of my acquaintance in Canada have been = required to provide a mapping between subscriber (CPE) MAC addresses and = assigned (DHCP) IPv4 addresses for customers of other ISPs who are using = the cable infrastructure as a wholesale product. Due perhaps in part to the fact that there is no defined, neat and tidy = way to store a MAC address in the DNS, different cable providers do it = in different ways. Some of them encode it in the owner name, some do it = in free-form TXT RDATA; some encode the IP address in an in-addr.arpa = fashion, some don't. I was motivated to try and make this better for the next place this kind = of uncoordinated requirement arises, since surely the wholesale internet = market in Canada cannot be unique. I have heard some musings from DHCP = software vendors about whether the ability to publish such a mapping = using DNS UPDATE directly from the DHCP servers would be useful. That = suggests to me that such vendors (who presumably are familiar with their = customers) think there are people who would like to use it. There's more to making a consistent schema for such an application than = defining an RRType, but the RRType existing certainly helps point things = in the right direction. I wasn't required to declare the motivation for the registration when I = sent in the form, and the expert review (as I understand it) wasn't = conducted on the basis of whether this was a useful idea, but on the = basis of whether this was something that couldn't use an existing = RRType, and had a stable specification. I can assure you that these registrations are not of zero value, even if = you don't seem them as something you would use. Joe From mstjohns@comcast.net Sun Apr 14 17:33:14 2013 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 6903521F8E51 for ; Sun, 14 Apr 2013 17:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.204 X-Spam-Level: X-Spam-Status: No, score=-100.204 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 YpmV7LFqsOhN for ; Sun, 14 Apr 2013 17:33:13 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0721F8CEC for ; Sun, 14 Apr 2013 17:33:13 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id Q0Yq1l0091ZXKqc580ZCvM; Mon, 15 Apr 2013 00:33:12 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta21.westchester.pa.mail.comcast.net with comcast id Q0ZB1l00M2kB7pQ3h0ZBXM; Mon, 15 Apr 2013 00:33:12 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Apr 2013 20:33:10 -0400 To: Joe Abley From: Michael StJohns In-Reply-To: <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365985992; bh=udQTwDi/RJWG7Sfq4jY79YrVDBIUdzc1kaSbPvzYFoE=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=YLdYUr6Sh9bCCLixnpwwRdcI9PVaGsFp4cFkH4rLrp/ebvzNl+AH7kiWNmoVPNfLX 7eAEAvt6GMD6hAakMxv6CWgmRLk73RYyBYMJCphz2mdb0amQNO8TZehIlr9yGz0Coh JCdPqE2THbu0Wx7jPyhuBEm4imLgxQmiIV2JZj4CFjgno/H0FI/JoqL3TDzwQk70q3 0p5eac8JLRa/mXzlLnsgk51Se7bAW6SEgHuZ40vOWYgZ0q2TnmMCEM2v+YGicS5+ro YkaKkhIw/IrKFAbA1hkU5eu/VwQkVgRK/1FBefNNgrbFvEEtRv9JQ0eiMsisCR/9on /jS58d3ruXHbg== Message-Id: <20130415003313.6CA0721F8CEC@ietfa.amsl.com> Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 00:33:14 -0000 At 06:56 PM 4/14/2013, Joe Abley wrote: >Hi there, > >On 2013-04-14, at 12:40, Michael StJohns wrote: > >> What exactly is the purpose for this document? Specifically, please describe the concept of operations for the use of this record. > >Regardless of whether it's required or not, there's no secret here and I believe I've mentioned the motivations more than once on this list. > >Some cable internet companies of my acquaintance in Canada have been required to provide a mapping between subscriber (CPE) MAC addresses and assigned (DHCP) IPv4 addresses for customers of other ISPs who are using the cable infrastructure as a wholesale product. > >Due perhaps in part to the fact that there is no defined, neat and tidy way to store a MAC address in the DNS, different cable providers do it in different ways. Some of them encode it in the owner name, some do it in free-form TXT RDATA; some encode the IP address in an in-addr.arpa fashion, some don't. > >I was motivated to try and make this better for the next place this kind of uncoordinated requirement arises, since surely the wholesale internet market in Canada cannot be unique. I have heard some musings from DHCP software vendors about whether the ability to publish such a mapping using DNS UPDATE directly from the DHCP servers would be useful. That suggests to me that such vendors (who presumably are familiar with their customers) think there are people who would like to use it. > >There's more to making a consistent schema for such an application than defining an RRType, but the RRType existing certainly helps point things in the right direction. > >I wasn't required to declare the motivation for the registration when I sent in the form, and the expert review (as I understand it) wasn't conducted on the basis of whether this was a useful idea, but on the basis of whether this was something that couldn't use an existing RRType, and had a stable specification. > >I can assure you that these registrations are not of zero value, even if you don't seem them as something you would use. I don't think this is of zero value, and I think it's probably more useful than not to have a consistent way of representing EUI stuff in the DNS. BUT - this has some potential to interact badly with DNS to IP(4/6) mappings for the same name. Although this is a straight data RR, it's semantics mean that an EUI RR directly represents an L2 capable device. That places it much closer to A and AAAA records and suggests that some guidance on how to reconcile names that have both IP content and EUI content is desirable. It also suggests that there may need to be some text in the security section describing privacy issues where the DNS name points to both the mac and the ip E.g. the mac is permanent, unique, and provides additional ways to identify specific users and relate identity to content. For example, a web server may do an inverse lookup on the IP address, gets an innocuous cable provider DNS name, uses that to look up the EUI and adds that information to its back end database for tracking purposes. Since that mac address never changes, the individual can be tracked even across DHCP updates, moving from one provider to another, etc. As I said in a private message to Paul Hoffman, I mostly don't care about random RR assignments, but I think this one needs a bit more thought and explanatory text. Mike >Joe From jabley@hopcount.ca Sun Apr 14 17:41:50 2013 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 90DC621F8E7B for ; Sun, 14 Apr 2013 17:41:50 -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 DjU0Cko8iI7M for ; Sun, 14 Apr 2013 17:41:49 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C868921F8D94 for ; Sun, 14 Apr 2013 17:41:49 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id a11so5273456iee.11 for ; Sun, 14 Apr 2013 17:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=EsKO7DqNU7UJ2HP79rZvsc87qDEpDau8Wu66uyv00fs=; b=KXDMk379MXBizQsJdYiCH+lZa2mmWA0vk2AwfiX3yVK86GOnU/+UxF4vlWhouyNSje V7AVfYPTaLV4QT6DPZJvN+/s2/ne4/hzC01rp07KrfDyH2coIhOg5qtz9M4ORrFU+CRL hiBaiAS8vTm3IWDNDdUUJVcaSETh+3CvnIqUw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=EsKO7DqNU7UJ2HP79rZvsc87qDEpDau8Wu66uyv00fs=; b=c08BaR7vbz0TUgKNln4CrsHcbHk2L8MhylNYTA31lqY+RuyYVhD47Uc6tkBxcnqsU/ LxmwOhB5PvEzdHPCu0v7yqq0d3fzcXarz32PH34Pl5MLtHvX66OFpo7TMmxDB+Onz9tr fpGQBUzyJ/+TKfRGq0Z4kEyLh4I49iwwbWQ9icmnyMIGvyQRaNoONWuiGEG209kWcdiX Vbh9sxf0tBEeT8SiQh/RQJs61YtXY6o3LVBJ7FkN3HfWI+LFuJT5oSZgsWAjXCnzBOGt Dx1Yw3PgtxQpSpj4KpXMth0qDsaO/c7AIOR2m0izq7OIvafy2/z+rm7pjeirJ6s/uG2f bj0Q== X-Received: by 10.50.51.131 with SMTP id k3mr4022420igo.54.1365986509230; Sun, 14 Apr 2013 17:41:49 -0700 (PDT) Received: from [10.23.45.64] (nat.teksavvy.com. [206.248.154.94]) by mx.google.com with ESMTPS id ip2sm8944274igc.5.2013.04.14.17.41.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 17:41:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> Date: Sun, 14 Apr 2013 20:41:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> To: Michael StJohns X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmy6q8N4SgERvolzZ3bmnJsNXjJijV+1sOWxdKKRgvo3vsDHAeOOb1KWMTkOMb5bEqoSQ7H Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 00:41:50 -0000 Hi again, On 2013-04-14, at 20:33, Michael StJohns wrote: > I don't think this is of zero value, and I think it's probably more = useful than not to have a consistent way of representing EUI stuff in = the DNS.=20 Thanks! > BUT - this has some potential to interact badly with DNS to IP(4/6) = mappings for the same name. Although this is a straight data RR, it's = semantics mean that an EUI RR directly represents an L2 capable device. = That places it much closer to A and AAAA records and suggests that some = guidance on how to reconcile names that have both IP content and EUI = content is desirable. =20 Since clients need to specify that they want an EUI48 or EUI64 RR in = order to receive an answer (or ask ANY, which these days mainly means = they want someone else to receive the answer) I don't see any conflicts = with existing cases of name resolution. Can you explain? > It also suggests that there may need to be some text in the security = section describing privacy issues where the DNS name points to both the = mac and the ip E.g. the mac is permanent, unique, and provides = additional ways to identify specific users and relate identity to = content. For example, a web server may do an inverse lookup on the IP = address, gets an innocuous cable provider DNS name, uses that to look up = the EUI and adds that information to its back end database for tracking = purposes. Since that mac address never changes, the individual can be = tracked even across DHCP updates, moving from one provider to another, = etc. With respect to privacy issues, the use case I described involves cable = plant/CMTS operators publishing data for use by their wholesale = customers. In Canada at least there is ample provision for privacy and = protection of both cable operators and ISPs for disclosure of data = relating to customers. I'm not sure such a wide-ranging discussion = really belongs in a brief protocol specification, though. Sounds more = like fodder for industry regulators and privacy commissioners. > As I said in a private message to Paul Hoffman, I mostly don't care = about random RR assignments, but I think this one needs a bit more = thought and explanatory text. I still don't see it myself, but if you feel strongly and wanted to = write up guidance for people using this particular RRType I'd be happy = to review it from the perspective of the use case I described. Joe= From dnsext.list@iswho.me Sun Apr 14 23:53:58 2013 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 788C321F8E94 for ; Sun, 14 Apr 2013 23:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 nKxWWXhIl5JO for ; Sun, 14 Apr 2013 23:53:57 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE321F8DA6 for ; Sun, 14 Apr 2013 23:53:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 62606207A3; Mon, 15 Apr 2013 02:53:53 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 15 Apr 2013 02:53:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=iswho.me; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= zICrIN0WmZbsPk85NDlZ9CurUdQ=; b=TzyaToWDDvuxFFg0lLJqWkpdqEi0bTxk yIYvWVQkPxx3R5gOUdpMIsSQn4Qhm8TGtm7VobrHet39fqpL7DDTcfoRF02bFSkx k131KES24QBIcvj7E4oSKATndFwlhVqIJcql/q20hvn7oCteNQWq0tFQ88Fa+WNf Uj5I/9AAPC8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=zICrIN0WmZbsPk85NDlZ9CurUdQ=; b=oYv PI9BnQbx6TDnlK4JhNcX7QZ9ifyt0E1eE0nVSHP9pwKJp9SQ/VusTcyb7O+rJ3Gy s/B6vIU0MENc9WyFHTuX9lurado4GlTEmA8cQuaT8VtwexUCH7EVmr+/3yFvMyez pYlhnBcoHxCyMDenLQUmBjShVCZYd4FqwRYinrw4= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 3B956B81C98; Mon, 15 Apr 2013 02:53:53 -0400 (EDT) Message-Id: <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> X-Sasl-Enc: 4fVRHWW/syF4n71r/AbGt+1vLk7dlz3P0e2e80cRdI/G 1366008833 From: list reader DNSEXT To: Joe Abley MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> Date: Mon, 15 Apr 2013 08:53:53 +0200 Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 06:53:58 -0000 Hi, I think there's an error in section 4.1 where it should say EUI64 but actually says EUI48. and +1 for the privacy concerned Regards ian maddison From jabley@hopcount.ca Mon Apr 15 04:53:52 2013 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 D826E21F93E2 for ; Mon, 15 Apr 2013 04:53:52 -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 fUktZAPV0JOL for ; Mon, 15 Apr 2013 04:53:52 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 112C521F93DC for ; Mon, 15 Apr 2013 04:53:51 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id k38so4293616iah.3 for ; Mon, 15 Apr 2013 04:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Ej73aomZXvFXWMtVS/G+w237yj193NKLQN056IlRDnc=; b=BLzkxS1dN7e2vK6BY3xveU1xEYn+BNtYIYSSnLflgLT3xIzjmVBWwOgUQp0EKZB7/f nAnouYNrVRWLHrvGBhaDY7/vVUQVB4AIvPYvffXiJSQClVFfGnXU5hiPZg1HJjDuUdE+ 2yiwQqewdS5PC00UWgQv3A1eLc1xLyA7gAIXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ej73aomZXvFXWMtVS/G+w237yj193NKLQN056IlRDnc=; b=YFbB3yGnV3GbxvwuIANLiQUBUHkHx/mcG0QKKErNgWGBL9Zm9N+lkzMJRpmgJG3E15 NTphWRMsm6AO8OQ89DCZzJR+YJ8h00FhiWxR1JhPK9bhCqz5aF7bW6ojjrUQPYJpz5iG eijn1Xi7uxbmFtsox4lLOopKAqV/sMZg9OLRk/nm/gyTXmqB1wz+2/W9E0uznuWpy9Tr E/bb7P+Cd4vSi+JJSvhtN8XjqpO/5wVEyACSalv4Cwyp7wpCqrUJVIHaAegoxqlVTePX 7FUi6OqZVkcOLi2bRa+k3klB/w7/BoUapv+n2WOW+O1WEvgl8YjXXSFmFuunNWIugMju fMWQ== X-Received: by 10.50.13.208 with SMTP id j16mr5295174igc.73.1366026830135; Mon, 15 Apr 2013 04:53:50 -0700 (PDT) Received: from [10.23.45.64] (nat.teksavvy.com. [206.248.154.94]) by mx.google.com with ESMTPS id ie7sm10621510igb.1.2013.04.15.04.53.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 04:53:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> Date: Mon, 15 Apr 2013 07:53:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> To: list reader DNSEXT X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkCU7ar88m9u/pxkdR5fYPlnRe9QIcOlJHlMlE10rywndGL/uoieikxdJ3INlMcNBJTa82j Cc: "dnsext@ietf.org Group" , dnsops@ietf.org, draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 11:53:53 -0000 On 2013-04-15, at 02:53, list reader DNSEXT = wrote: > I think there's an error in section 4.1 where it should say EUI64 but > actually says EUI48. I think you're right. Thanks for that! I will make changes. > and +1 for the privacy concerned Can you explain further? I don't understand those concerns. This document provides a specification for a structured way of storing = particular data in the DNS. It's not data that can't be stored today = using more general RRTypes like TXT. It doesn't advocate publication of = anything. What are the privacy concerns? If there are concerns that people should take time to understand the = privacy implications of publishing subscriber data in the DNS, then that = seems entirely valid. But this is not a draft about publishing = subscriber data in the DNS, it's a draft about implementing specific = RRTypes. If there is useful information for the IETF to publish about privacy = considerations in the DNS, I don't understand why that should be = specific to these particular RRTypes. Are similar privacy concerns not = also applicable to the DNS in general? I've seen people distribute password hashes and user identities in the = DNS before, as a back-end to tacacs servers deployed to authenticate = dial-up users. (OK, this is going back a bit.) Surely if there is advice = to be given about the publication of subscriber data in the DNS we would = want to talk about the general approach, and not specific RRTypes. Would we caution people about storing MAC addresses in an EUI48 RR, but = not bother to caution other people about storing the same data in TXT = records? etc, etc. Joe= From envite@rolamasao.org Mon Apr 15 05:44:38 2013 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 C85B721F9362 for ; Mon, 15 Apr 2013 05:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.996 X-Spam-Level: ** X-Spam-Status: No, score=2.996 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp+Ypa2-uEnx for ; Mon, 15 Apr 2013 05:44:37 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE821F9352 for ; Mon, 15 Apr 2013 05:44:36 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id C6A7011EA7 for ; Mon, 15 Apr 2013 13:44:33 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Mon, 15 Apr 2013 13:44:29 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201303171259.07860.envite@rolamasao.org> <20130319035805.GA19020@vacation.karoshi.com.> <201304071353.33136.envite@rolamasao.org> In-Reply-To: <201304071353.33136.envite@rolamasao.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart97596887.NqmRbfFF28"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201304151344.29996.envite@rolamasao.org> Subject: Re: [dnsext] DNS-like system for OID [WAS: Presentation and question] 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, 15 Apr 2013 12:44:38 -0000 --nextPart97596887.NqmRbfFF28 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does somebody with a bit of experience writing RFC Draft proposals want to= =20 help with this? Thanks On Domingo, 7 de abril de 2013 13:53:31 Noel David Torres Ta=F1o wrote: > On Martes, 19 de marzo de 2013 03:58:05 bmanning@vacation.karoshi.com wro= te: > > my my.. Steve Hotz and I did this 20 years ago - when the DNS was much > >=20 > > less ossified than it is today. we started w/ new class, ended up > > anchoring in the int. tree (when we had emptied out arpa of everything > > but in-addr.... but that is another story). > >=20 > > it didn't get much traction then, would be happy to work on it again. > >=20 > > /bill >=20 > Skeleton would be like this: >=20 > Rationale: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current DNS IN class schemene intends to trace between a tree-like > structure (the domain names, rooted at . ) and a linear structure (the IP > addresses, between 0.0.0.0 and 2555.255.255.255 ) . It has been extended > to include IPv6 addresses, but these are a linear structure too (from :: > to > FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ) . IN class also includes an > inverse resolution (from linear IP to tree-like Domain Names) which is a > tweak which really resolves between IP-like Domain Names and real Domain > Names and also does not address fully issues like IP delegation in > non-8bit boundaries (See RFC 2317 ) . > OID, instead, is a tree-like structure on its own, with (currently) three > roots (0, 1 and 2) which can be super-rooted at . so this "skeleton > proposal" intends to draw a way to map from tree-like structure to > tree-like structure, fully forward and backwards, including also extra > information that may be deemed useful. > Also, this proposal allows OID owners to publicily state about canonical > hostnames where information about their OIDs (or the organizations holding > them) can be found. >=20 > 8<----------------------------------------------------------- >=20 > This "skeleton proposal" uses class name OID throught it. >=20 > Notes: > =3D=3D=3D=3D=3D=3D >=20 > Names and numbers are displayed from root to leaf, unlike in DNS IN class. >=20 > Resource Record Types: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > SOA: Similar to that of IN class, there will be two SOA registers to > maintain, one for number-name conversion and one for name-number. >=20 > OID: Similar to A or AAAA of IN class, will be used only for name-number > conversion. >=20 > NAME: Similar to PTR of IN class, will be used only for number-name > conversion. >=20 > NS: Equivalent to that of IN class, will point to oid-capable nameservers > which hold thata for the current zone, being this either number->name or > name- >=20 > >number. >=20 > DNS: Available in number->name zone only (they can be reached from a name > if you perform a name->number search first and an A search afterwards). > They point to the canonical IN DNS hostname for the OID, however it is > defined by OID owner. >=20 > TXT: These are available in name->number zone only (they can be reached > from a number if you perform a number->name search first and a TXT search > afterwards). They can include whichever information OID ownser deems > necessary, much like IN class TXT records. >=20 > EQUIV: These are available in both zone types, and are similar to IN class > CNAME. It indicates that all searches that may be conducted after one OID > number or name are to be conducted after another OID number or name > instead. No mixture of numbers and names allowed. This RR specifically > claims that subtrees under the two OIDs are exactly equal. >=20 > Example resource records: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > ;-------------- > ;NAME zone > .iso.identified-organization.dod.internet.private.enterprise.rolamasao-org > OID SOA (ns.rolamasao.org envite.rolamasao.org 2013040701 172800 86400 > 2419200 604800) >=20 > @ OID NS ns.rolamasao.org > @ OID NS ns2.rolamasao.org >=20 > @ OID TXT "Rolamasao.org related elements" >=20 > @ OID OID .1.3.6.1.4.1.41434 >=20 > persona OID OID 1 > individual OID OID 2 > individual OID EQUIV persona >=20 > ;NUMBER zone > .1.3.6.1.4.1.41434 OID SOA (ns.rolamasao.org envite.rolamasao.org > 2013040701 172800 86400 2419200 604800) >=20 > @ OID NS ns.rolamasao.org > @ OID NS ns2.rolamasao.org >=20 > @ OID NAME .iso.identified- > organization.dod.internet.private.enterprise.rolamasao-org >=20 > @ OID DNS www.rolamasao.org >=20 > 1 OID NAME persona > 2 OID NAME individual > 2 OID EQUIV persona > ;-------------- >=20 > Recursive search: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Due to exact tree-to-tree mapping, and to avoid long strings like > ".iso.identified-organization.dod.internet.private.enterprise.rolamasao-o= rg > " it is allowed to make short references like these: >=20 > INSTEAD OF > @ OID OID .1.3.6.1.4.1.41434 > IT IS ALLOWED > @ OID OID 41434 >=20 > INSTEAD OF > @ OID NAME .iso.identified- > organization.dod.internet.private.enterprise.rolamasao-org > IT IS ALLOWED > @ OID NAME rolamasao-org >=20 > These not-starting-with-dot records will force recursive search. >=20 > Root of the trees: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Nominally the root of both trees will be . but all clients should know th= at > the real roots are 0. 1. and 2. for numbers and itu-t. iso. and > joint-iso-itu- t. for names. >=20 > 8<----------------------------------------------------------- >=20 > Please comment (yes, this is a request for comments but not a Request For > Comments yet). > Noel Torres > er Envite > ------------------------- > A: Because it breaks the logical flow of discussion. > Q: Why is top posting bad? =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart97596887.NqmRbfFF28 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlFr9i0ACgkQcLQA8+7Hw3Ja1ACfSQCO3GgAJ+uvPGbEFmeF9Lhk 80QAn0x3/cHkocOwDV/zb1IaQTHDtawi =x0Ij -----END PGP SIGNATURE----- --nextPart97596887.NqmRbfFF28-- From bdickson@verisign.com Mon Apr 15 08:51:49 2013 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 0E18421F9427 for ; Mon, 15 Apr 2013 08:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 AZhwWS10WkKJ for ; Mon, 15 Apr 2013 08:51:48 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id B473B21F940E for ; Mon, 15 Apr 2013 08:51:46 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUWwiC04pq9o+h0IXV7++zq/dWKpBxisP@postini.com; Mon, 15 Apr 2013 08:51:48 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r3FFpaUk015537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 11:51:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 11:51:36 -0400 From: "Dickson, Brian" To: Michael StJohns , Donald Eastlake Thread-Topic: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... Thread-Index: AQHOOWHEsAjncdTQY0agHe/vsGJx2pjXb3CA Date: Mon, 15 Apr 2013 15:51:35 +0000 Message-ID: In-Reply-To: <20130414224537.CD72321F8C55@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <65A9FF33D5E8EF48993742102F4C1B54@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" , "dnsops@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 15:51:49 -0000 Michael StJohns wrote: > > But getting back to the current case - > > 1) If you query the DNS for both an IP and a MAC address, and you get >records for both, but the records don't point to the same physical host, >what should you do, and how might you detect this? > > 2) If you query the DNS for MAC address records and you get multiple >records for the same DNS name, what does that mean? > > 3) If you query the DNS for an IP and MAC address and only get a MAC >address record, what does that mean? >=20 > 4) If you query the DNS for an IP and a MAC, and then ARP for the MAC >address and get a different value than the MACs from the DNS, what does >that mean? All of the above suffer from "pronoun trouble". Who is "you", in each case above? While DNS can be queried by humans, its main raison d'=EAtre is use by machines. So, what is doing the query/queries? And presumably, it is doing so because of some standard for using DNS for the relevant info. And, the behavior would, I would expect, be defined by that protocol/application, including how to handle the above cases. Your questions might be turned around, and ask the question: - what protocol would be doing queries for both (A or AAAA) and (EUI-48 or EUI-64)? - what protocol would be doing queries for just (EUI-48 or EUI-64)? And each question's answer might quite reasonably differ, based on the application/protocol doing the queries. Examples for IP+MAC might include: - DHCP servers - IPS/IDS/Firewall systems - enhanced ACLs on servers - anything doing static ARP - anything doing reverse-arp Similarly, what kinds of things might be involved in setting EUI-48/EUI-64 records? - dynamic update related to wifi (authenticated registration) - layer 2 protection schemes (especially for IPv6 vs ND/RA/etc) - zeroconf (multicast DNS), and perhaps mdnsext I'd humbly suggest that the variety of potential use cases already meets the "need" you have articulated. Having defined RRTypes is an enable for all of the above. Brian From joelja@bogus.com Mon Apr 15 09:03:42 2013 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 00F8121F8EDA; Mon, 15 Apr 2013 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 zJrdUUrlUlbU; Mon, 15 Apr 2013 09:03:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7350421F84CE; Mon, 15 Apr 2013 09:03:41 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3FG3cHw054141 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 15 Apr 2013 16:03:39 GMT (envelope-from joelja@bogus.com) Message-ID: <516AFED4.5000504@bogus.com> Date: Sun, 14 Apr 2013 12:09:08 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Michael StJohns References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> In-Reply-To: <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 15 Apr 2013 16:03:39 +0000 (UTC) Cc: "dnsop@ietf.org" , "dnsext@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:03:42 -0000 On 4/14/13 9:40 AM, Michael StJohns wrote: > What exactly is the purpose for this document? Specifically, please > describe the concept of operations for the use of this record. The rational described on this list a month ago was as follows: -------- Original Message -------- Subject: [dnsext] Fwd: New Version Notification for draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt Date: Tue, 19 Mar 2013 10:33:04 -0400 From: Joe Abley To: dnsext@ietf.org Group Hi all, During a conversation about an attempt to stuff IP and subscriber MAC addresses into the DNS (something that is happening operationally in Canada, related to wholesale cable internet service) I noticed that there is currently no clean way to represent ethernet MAC addresses. People are either using TXT records, or encoding MAC addresses into PTR RDATA, and it's all a bit messy. Assuming that this is not the last time that someone will find a reason to encode layer-2 addresses in the DNS, I thought it worthwhile to define a cleaner option. The draft referenced below defines two new RRTypes, EUI48 (for EUI-48 addresses, which is what prompted this line of thinking) and EUI64 (for EUI-64 addresses, since it seems silly to accommodate one without the other). The wire format is pretty trivial (network byte order, simple octet string), the RRTypes chosen are unremarkable (not sure what else you'd call an EUI-48 address RRType than EUI48) and the presentation format should be familiar. The examples given use the ethernet address of the wireless adapter on my laptop and its EUI-64 mapping, for lack of any documentation OUI that I could find. The IEEE references are consistent with the references for EUI-64 in IPv6, e.g. in RFC 4291. The expert review template for the RRType application is included as an appendix. In the event that this proposal doesn't meet with projectile heartburn, I would hope that this could be adopted, discussed, refined and last-called before the demise of dnsext. Alternatively, assuming again that the expert review raises no concerns and code points are assigned, it could proceed as an individual-track submission. Comments welcome. Joe > > Mapping a name directly to a MAC address seems somewhat problematic > and perhaps even dangerous to consistency. > > I understand storing things in the DNS system is attractive, but > adapting it to store L2 data may be going a bit too far past it's > designed scope, The scope in which such a mapping is useful is clearly fairly limited, I imagine there are provisioning/subscriber managment systems that would adopt such a representation, but I imagine the author has a more specifc example. > I would object to the document absent a clear and convincing > description of why it is needed and what applications will use it. > > Mike > > Sent from my iPad > > On Apr 14, 2013, at 11:55, joel jaeggli wrote: > >> I've been asked to take this document on as AD sponsored individual >> submission. >> >> http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 >> >> >> If there's anyone who has strenuous objections to that, please let me know. >> >> joel _______________________________________________ dnsext mailing >> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > From dougb@dougbarton.us Mon Apr 15 09:11:01 2013 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 1C1D821F958D for ; Mon, 15 Apr 2013 09:11:01 -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 LXsR1QRb3iWL for ; Mon, 15 Apr 2013 09:11:00 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7021F9420 for ; Mon, 15 Apr 2013 09:11:00 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b1c8:882b:d2c5:4659] (unknown [IPv6:2001:470:d:5e7:b1c8:882b:d2c5:4659]) by dougbarton.us (Postfix) with ESMTPSA id 2FA1E22C28 for ; Mon, 15 Apr 2013 16:11:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366042260; bh=a9bEjXDgEpvGft1PRQUjKrextUIbO/SLjxYJ3wNnjfI=; h=Date:From:To:Subject:References:In-Reply-To; b=Dy0FxfADL+troHrbiluAPoCmOgTiHuuXdThb5w7ygFwvfJckL6xWVsEz2nz3mv3BF Q4CA2Lx5rEoQgqL5YF+yUkRlDXu9Bsn6lA0YRvirjwpB20k0spzel+GJ6Q39cbofjV RZA6p3hW/b8r0qcSBoSsP9qmrGxkOzQQoeUXMZ7k= Message-ID: <516C2693.2050506@dougbarton.us> Date: Mon, 15 Apr 2013 09:10:59 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> In-Reply-To: <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:11:01 -0000 On 04/14/2013 03:56 PM, Joe Abley wrote: > I was motivated to try and make this better for the next place this kind of uncoordinated requirement arises, since surely the wholesale internet market in Canada cannot be unique. I have heard some musings from DHCP software vendors about whether the ability to publish such a mapping using DNS UPDATE directly from the DHCP servers would be useful. That suggests to me that such vendors (who presumably are familiar with their customers) think there are people who would like to use it. Personally I would like to see a more well-defined use case for this before RRtypes are actually assigned. It's not at all clear why the right answer isn't a common definition of how to do this in a TXT record. Not everything needs (or should have) it's own RRtype. It's also not clear why IANA has already assigned code points for this (as described in your text). Doug From jabley@hopcount.ca Mon Apr 15 09:18:18 2013 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 5C30121F875C for ; Mon, 15 Apr 2013 09:18:18 -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 rUWCgeHNUHHY for ; Mon, 15 Apr 2013 09:18:17 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFC21F86B2 for ; Mon, 15 Apr 2013 09:18:17 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so4536105iag.36 for ; Mon, 15 Apr 2013 09:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=rDpDj45jyx+EGGXYUAMxgW+6trYVDBe3z15h8Ap3xos=; b=afGvsFJ4X32ndzcfjMpw9NtgUY16YaHdyTO9ndMjGARiMgWuK9t9WvxA2O6nEuy6AM f21bBM/gprXqClcJHEjTsLkDHNoYV4zVYs5lyUCDRSls1vfHwh8RsZOOaJbR7X6TI/pm PrkLsNsgXx1RYz5PNuJ3MA5mkjsr9t7iVbUSU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rDpDj45jyx+EGGXYUAMxgW+6trYVDBe3z15h8Ap3xos=; b=NjbEXZ+iXXsk8iNNzypTRGyQtgiSXXfDYg/UiZf6ROV+7bkPL0XlF2CphuqeENqMfZ XZwspb+WX1nZ+Ub1YhdE0YID/epwpZsPhxxKoXamCCry53zjbjLNOnnvg0Ro/lj32PKI tav5zpCb6UcXFTMdr0O6NcBFutyD5gONGWyt+d3KPATIGvOqZppWd/6p97qDPeQ/ac0l wRuj7u1OTGm4jzbm2gqg7DxktSdBFqNE8HxAkXBnbdCQRxjvQvfhp0m+I6xObsYaPeQ8 /2KghKbTAnxcIMAxA8kCzXyKmiYa5lSMeIQ8uIpKzUlJcCpyo9ZMu3aJNWQATBhuak9T bf9w== X-Received: by 10.50.108.39 with SMTP id hh7mr5782883igb.109.1366042697117; Mon, 15 Apr 2013 09:18:17 -0700 (PDT) Received: from tekmobile17.teksavvy.web (nat.teksavvy.com. [206.248.154.94]) by mx.google.com with ESMTPS id wn10sm11531284igb.2.2013.04.15.09.18.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 09:18:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <516C2693.2050506@dougbarton.us> Date: Mon, 15 Apr 2013 12:18:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmFsHGwS99P4gFjN5P8owbwGdlEu/GkPIWKjAlf2mTssALSoJ1hRdvwjbaK/lBIlAp98pqz Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:18:18 -0000 On 2013-04-15, at 12:10, Doug Barton wrote: > It's not at all clear why the right answer isn't a common definition = of how to do this in a TXT record. Not everything needs (or should have) = it's own RRtype. I think this is madness. By this logic we didn't need to bother defining AAAA records, since = there's no reason why they can't live in TXT records. Ditto DNSKEY, and = everything, really. Why even have RRTypes, if we can just ship free-form = text around? > It's also not clear why IANA has already assigned code points for this = (as described in your text). Because the expert review passed, and IANA was following the required = procedure, I think. Joe= From jim@rfc1035.com Mon Apr 15 09:38:58 2013 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 0060B21F94D0 for ; Mon, 15 Apr 2013 09:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmndDZkjx8d8 for ; Mon, 15 Apr 2013 09:38:57 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7236A21F9497 for ; Mon, 15 Apr 2013 09:38:57 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 34E09CBC41F; Mon, 15 Apr 2013 17:38:55 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Mon, 15 Apr 2013 17:38:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FAFDB06-31C9-4AC6-B520-288229881EC4@rfc1035.com> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:38:58 -0000 On 15 Apr 2013, at 17:18, Joe Abley wrote: > On 2013-04-15, at 12:10, Doug Barton wrote: >=20 >> It's not at all clear why the right answer isn't a common definition = of how to do this in a TXT record. Not everything needs (or should have) = it's own RRtype. >=20 > I think this is madness. +100. > By this logic we didn't need to bother defining AAAA records, since = there's no reason why they can't live in TXT records. Ditto DNSKEY, and = everything, really. Why even have RRTypes, if we can just ship free-form = text around? Indeed. The "just make everything a TXT record" mindset is nuts. How is an = application making a QTYPE=3DTXT query expected to make sense of = possibly zillions of TXT records in the response, filtering the wheat = from the chaff? What's the operational impact of that? Going further = down that path probably means having to subtype TXT records while RR = type codes go unassigned. Sheer madness. >> It's also not clear why IANA has already assigned code points for = this (as described in your text). >=20 > Because the expert review passed, and IANA was following the required = procedure, I think. In other words, we're done. The type codes have been assigned. That ship = has already sailed. An RFC documenting these RRTypes and how they're used is to be welcomed. = After all that draft didn't *have* to be written. Further discussion on = this thread should be about improving that document. For instance by = contributing text to explain the potential for unwelcome interactions = with A/AAAA/PTR mappings for the same name that Mike mentioned the other = day. The question of "why not do this in a TXT record?" has already been = satisfactorily answered and IMO is no longer up for debate. From dougb@dougbarton.us Mon Apr 15 09:42:35 2013 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 27C5721F9614 for ; Mon, 15 Apr 2013 09:42:35 -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 NEeSZR-E+zRu for ; Mon, 15 Apr 2013 09:42:34 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCFF21F9612 for ; Mon, 15 Apr 2013 09:42:34 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b1c8:882b:d2c5:4659] (unknown [IPv6:2001:470:d:5e7:b1c8:882b:d2c5:4659]) by dougbarton.us (Postfix) with ESMTPSA id 4C29B22C21 for ; Mon, 15 Apr 2013 16:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366044154; bh=yuey6Swjs7PNl8DWlBeN1FRP2S19i8Y/roqiYavfEAM=; h=Date:From:To:Subject:References:In-Reply-To; b=vdJz79mfxYy9CJKIR32tKOCWi3Uoag/7tsqw+NSDH6uRh5nv3eH/txznGWHOEn2wz THNM/kM2YYp2j+dO9gr30UPo0sbCeXyV8xM8nqoOWwm3AxKV32RcZLtM6713fPHd4R LYdNw3RqrsV4CnLH4Vk/Ykn6AuGzkOIivDYlALwY= Message-ID: <516C2DFA.20809@dougbarton.us> Date: Mon, 15 Apr 2013 09:42:34 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:42:35 -0000 On 04/15/2013 09:18 AM, Joe Abley wrote: > > On 2013-04-15, at 12:10, Doug Barton wrote: > >> It's not at all clear why the right answer isn't a common definition of how to do this in a TXT record. Not everything needs (or should have) it's own RRtype. > > I think this is madness. > > By this logic we didn't need to bother defining AAAA records, since there's no reason why they can't live in TXT records. Ditto DNSKEY, and everything, really. Why even have RRTypes, if we can just ship free-form text around? Don't be absurd. You're smart enough to know the difference between something that is widely or near-universally deployed, and something that is a special case for a limited number of environments; and the relative value of exhausting a scarce resource for each. Or is your argument that everyone who applies should get an RR code point, until they're all gone? FWIW, we did something similar when I was at Yahoo!, and I know from experience that TXT works just fine for this purpose. As I said in my first message, I am not opposed to assigning RRtypes for this per se, but I don't think that the use case is well enough documented to justify it yet. >> It's also not clear why IANA has already assigned code points for this (as described in your text). > > Because the expert review passed, and IANA was following the required procedure, I think. Fair enough. I'm not as familiar with the fine points of the procedure as I used to be. :) Doug From bdickson@verisign.com Mon Apr 15 09:53:04 2013 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 4FDDE21F8FDB for ; Mon, 15 Apr 2013 09:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 viB9HJa7-qOG for ; Mon, 15 Apr 2013 09:53:01 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 54EEB21F8F70 for ; Mon, 15 Apr 2013 09:52:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUWwwasQff1JxKpnGd6Ao1Xx2gO3ES5fk@postini.com; Mon, 15 Apr 2013 09:53:01 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r3FGqnOo017795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 12:52:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 12:52:49 -0400 From: "Dickson, Brian" To: Jim Reid , Joe Abley Thread-Topic: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... Thread-Index: AQHOOfmp1QSd6R3Q2E+KBXz29OQiDQ== Date: Mon, 15 Apr 2013 16:52:48 +0000 Message-ID: In-Reply-To: <0FAFDB06-31C9-4AC6-B520-288229881EC4@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:53:04 -0000 On 4/15/13 12:38 PM, "Jim Reid" wrote: > >The question of "why not do this in a TXT record?" has already been >satisfactorily answered and IMO is no longer up for debate. > + 2^16 :-) Anyone still suggesting use of TXT, please read RFC 5507 (http://tools.ietf.org/html/rfc5507), which answers this in a canonical fashion. Brian From nweaver@icsi.berkeley.edu Mon Apr 15 09:57:05 2013 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 E4ABC21F9620 for ; Mon, 15 Apr 2013 09:57:05 -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 9LpYnGJ+qjnH for ; Mon, 15 Apr 2013 09:57:05 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 463D421F9632 for ; Mon, 15 Apr 2013 09:57:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2ABD92C4036; Mon, 15 Apr 2013 09:57:05 -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 6IkNgH0alYG3; Mon, 15 Apr 2013 09:57:04 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id ABD832C400D; Mon, 15 Apr 2013 09:57:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: <516C2DFA.20809@dougbarton.us> Date: Mon, 15 Apr 2013 09:57:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74C256F0-7262-45F7-8D3D-AE461A72E459@icsi.berkeley.edu> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516C2DFA.20809@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 16:57:06 -0000 On Apr 15, 2013, at 9:42 AM, Doug Barton wrote: > Don't be absurd. You're smart enough to know the difference between = something that is widely or near-universally deployed, and something = that is a special case for a limited number of environments; and the = relative value of exhausting a scarce resource for each. >=20 > Or is your argument that everyone who applies should get an RR code = point, until they're all gone? >=20 > FWIW, we did something similar when I was at Yahoo!, and I know from = experience that TXT works just fine for this purpose. As I said in my = first message, I am not opposed to assigning RRtypes for this per se, = but I don't think that the use case is well enough documented to justify = it yet. I rather find the opposite: I don't see why this is NOT a good use of = DNS. DNS is, first and foremost, about tying names to network address = information. This is simply one common piece of addressing information = that does not already have a type assigned. So the real question is "is it broad enough"? Yes, since just about = every L2 network technology has a 48B or 64B fixed address size. And its not like we need to worry about RR space exhaustion, we are only = using what, .5% of the space for allocating new RR types? From dougb@dougbarton.us Mon Apr 15 10:10:12 2013 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 3B01421F961E for ; Mon, 15 Apr 2013 10:10:12 -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 fzJ6u7JQOVPB for ; Mon, 15 Apr 2013 10:10:10 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3021F93CC for ; Mon, 15 Apr 2013 10:10:10 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:a48f:52e9:33a6:1295] (unknown [IPv6:2001:470:d:5e7:a48f:52e9:33a6:1295]) by dougbarton.us (Postfix) with ESMTPSA id 14A4922C21 for ; Mon, 15 Apr 2013 17:10:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366045805; bh=I84nIvnErKBsdkR/CEUWrLzqKp4lwUbpd/S7mukpWTs=; h=Date:From:To:Subject:References:In-Reply-To; b=OVGRsq5byS+Gfu4SCilnK510YLpgMDZGW2Nj+1YnyJvfYZ1EdGk+GUq4TxBlnMJs/ fAEz5hUKmxSnYQ8GcbUEz4cdXR5qe8tTpU7TWfSIKmM+X3ulz2szJgbs0KNKxAv0Gp irIUUbfl37M6gDBjjUDxpJbDZIq4gKGCmBKko8HE= Message-ID: <516C346C.5050507@dougbarton.us> Date: Mon, 15 Apr 2013 10:10:04 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 17:10:12 -0000 On 04/15/2013 09:52 AM, Dickson, Brian wrote: > > > On 4/15/13 12:38 PM, "Jim Reid" wrote: >> >> The question of "why not do this in a TXT record?" has already been >> satisfactorily answered and IMO is no longer up for debate. >> > > + 2^16 :-) > > Anyone still suggesting use of TXT, please read RFC 5507 > (http://tools.ietf.org/html/rfc5507), which answers this in a canonical > fashion. Been there, done that, got the t-shirt. For things that are going to be generally useful I have no argument with assigning an RRtype (as I've said many times now). But the mere fact that something is in an RFC doesn't mean that I have to agree with it carte blanche, does it? Not to mention that 5707 is Informational, so by definition non-canonical. :) Doug From jabley@hopcount.ca Mon Apr 15 10:21:05 2013 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 9D24D21F9428 for ; Mon, 15 Apr 2013 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.265 X-Spam-Level: X-Spam-Status: No, score=-97.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, 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 Q3NX7tK48KvG for ; Mon, 15 Apr 2013 10:21:04 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6087321F9412 for ; Mon, 15 Apr 2013 10:20:55 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id h23so4442836iae.14 for ; Mon, 15 Apr 2013 10:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=eHxEIC562mO5OtUwjia7GDbkpFj89C1VSzGie4H6JQE=; b=luG7Zz7h3/yti0h1zxcDIN0qqlTCNUs2HVV+nJHML6pSMwELX+li9XSVVCbbVO9E1f WVVqKf8siequoTF0hjoiR2jXQXmq27GwT1O4sYlhQIZLCQDLpszA/DFkp0mW/8Jhcg3D R1Whp4qlPcr0Fp4daOvbsbLBfZxk8r34h4VJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=eHxEIC562mO5OtUwjia7GDbkpFj89C1VSzGie4H6JQE=; b=f1tlE3W9DNaTPwcu1SosR5wQoU4PlUn+s4kUuVfHrpquv6mzcCQBsnqHICpbEjmZD1 Gz4SsiMp2fqgtIVGOmmaobhaNWhJD7WrqdlvtKFPq3f4owK434ULzVzeMs2x+EqqBN0G yqmnCo2vHSLR2o1yRxGt57vlfdJwRUZAHvD4UzHrtJNzFu8+K2mh80Zc0TKsXaX5UlrR Cja/AWHyKZCZ7vQC6ABgcVsl4vuzA1cByOt/LwMrkJztvZKCX7LnuihWHlSgatRK5CUw XJIcqkKPKssTc1x0Wq3/dJdNkG0ez0bKhAKDKQt+IhFBR3SSLqx7aB0PoGLCSSmCBSr0 3jmw== X-Received: by 10.50.93.3 with SMTP id cq3mr5938943igb.70.1366046454833; Mon, 15 Apr 2013 10:20:54 -0700 (PDT) Received: from [10.169.22.36] (out-on-164.wireless.telus.com. [207.219.69.164]) by mx.google.com with ESMTPS id a3sm13030846igq.5.2013.04.15.10.20.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 10:20:54 -0700 (PDT) References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516C2DFA.20809@dougbarton.us> Mime-Version: 1.0 (1.0) In-Reply-To: <516C2DFA.20809@dougbarton.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0BC57CBA-552B-4DC6-A7B7-123A58112E16@hopcount.ca> X-Mailer: iPad Mail (10B329) From: Joe Abley Date: Mon, 15 Apr 2013 13:20:55 -0400 To: Doug Barton X-Gm-Message-State: ALoCoQlfCEvVTuToWTzR+tUa63OeL0mHe/uzjrRfcBZr7TBe0dhtx1lhUTUCuCZ0vXbuKTBcqe6x Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 17:21:05 -0000 On 2013-04-15, at 12:42, Doug Barton wrote: > On 04/15/2013 09:18 AM, Joe Abley wrote: >>=20 >> On 2013-04-15, at 12:10, Doug Barton wrote: >>=20 >>> It's not at all clear why the right answer isn't a common definition of h= ow to do this in a TXT record. Not everything needs (or should have) it's ow= n RRtype. >>=20 >> I think this is madness. >>=20 >> By this logic we didn't need to bother defining AAAA records, since there= 's no reason why they can't live in TXT records. Ditto DNSKEY, and everythin= g, really. Why even have RRTypes, if we can just ship free-form text around?= >=20 > Don't be absurd. You're smart enough to know the difference between someth= ing that is widely or near-universally deployed, ... like ethernet... > and something that is a special case for a limited number of environments ... like DNSSEC or IPv6 when AAAA and DNSKEY were assigned, or, even arguabl= y, now? > ; and the relative value of exhausting a scarce resource for each. >=20 > Or is your argument that everyone who applies should get an RR code point,= until they're all gone? I certainly don't think we should be turning down RRType applications on the= grounds that one day we might possibly run out of code points. By that logi= c, we'd never assign any at all. Fortunately, the question at hand is not whether you think assignment is a g= ood idea (code points have already been assigned) or whether this is somethi= ng you would ever use (feel free not to). The question is whether the docume= nt provides reasonable documentation that could facilitate implementation an= d interop. Do you have any opinions on that? > FWIW, we did something similar when I was at Yahoo!, and I know from exper= ience that TXT works just fine for this purpose. I had no idea Yahoo! was involved with implementing CRTC policy decades befo= re it was enacted, that's certainly impressive. > As I said in my first message, I am not opposed to assigning RRtypes for t= his per se, but I don't think that the use case is well enough documented to= justify it yet. Noted, but your opinion (or anybody else's) on these assignments is not actu= ally relevant here. Joe= From mstjohns@comcast.net Mon Apr 15 15:11:44 2013 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 03FDE21F9402 for ; Mon, 15 Apr 2013 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 nlKG89biqb1F for ; Mon, 15 Apr 2013 15:11:43 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57721F93F3 for ; Mon, 15 Apr 2013 15:11:43 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id QMgF1l0030vyq2s57NBiiv; Mon, 15 Apr 2013 22:11:42 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta05.westchester.pa.mail.comcast.net with comcast id QNBh1l0012kB7pQ3RNBhQl; Mon, 15 Apr 2013 22:11:42 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Apr 2013 18:11:42 -0400 To: Joe Abley ,list reader DNSEXT From: Michael StJohns In-Reply-To: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366063902; bh=DqhAsIwBkksdkWKstUDV+giGQCNnxe0AHEiwrNGulKo=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=gzfbuTxFUijMIFE3F+PfqXCjKqAp0VZk+8j92cqywnIejBwWYFxpHx30KNad0NSZ/ Qhq3KftOyb6Oo1OpnquKt2gICbuqnEYNYSeQLzXZXF4rtk8CF7RSFUixtv0GA/laDQ aVy386TiGqcQG0L1LnhwkDYfCy4OyjV1pq0vmDzAkX1UR8VCkNVslB3ylAu0XZKysh h1YglWfMdc4i8pEaMcaYXY6TwUkoML6CrhOj1LQfuYRLrDNp0mHWlOwBFJSN+Fn3yc 4lDQ/6ki3By9wtX0qFgKXV22biBQUqdi1W5lfvBQBbLGhMvXRfMRyUvPRW/hPongRE pE3P3a5eDHLvg== Message-Id: <20130415221143.2E57721F93F3@ietfa.amsl.com> Cc: "dnsext@ietf.org Group" , dnsops@ietf.org, draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 15 Apr 2013 22:11:44 -0000 At 07:53 AM 4/15/2013, Joe Abley wrote: >On 2013-04-15, at 02:53, list reader DNSEXT wrote: > >> I think there's an error in section 4.1 where it should say EUI64 but >> actually says EUI48. > >I think you're right. Thanks for that! I will make changes. > >> and +1 for the privacy concerned > >Can you explain further? I don't understand those concerns. Suggested paragraphs for the security section. [ PRIVACY: There may be privacy concerns with publishing EUI RRs. EUI64 and EUI48 represent unique identifiers for network connected equipment. As such, their inclusion within the DNS may result in privacy issues in the form of unique trackable identities. Unlike the IP addresses and DNS names for network devices which can and do change over time, the EUI information will almost always uniquely identify a device (or more specifically, a network interface). As an example of this, consider a wireless provider that publishes EUI information for its subscribers. An entity that wants to relate web queries, for example, to a specific customer need only do a reverse query from the IP address to a DNS name, and then a forward query for the EUI information. The tracking entity may relate all queries to specific unique identities regardless of changes in IP addresses and DNS names resulting in a possible loss of privacy for the subscriber. Transitive Trust: DNSSEC allows the binding of a name to one or more RR's. It is possible to use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same name. This should probably not be consider as a secure binding between an IP address and an EUI64/48 address. {Not sure where this should go - this gets perilously close to secure ARP and placing this in the hands of the domain owner rather than the hands of the network owner is probably a "bad thing" } Paragraph for the main body: [ EUI64 and EUI48 addresses represent another way of referencing a network connected host past IP addresses and DNS names. Any system which deploys EUI64 and EUI48 RR's should consider how to maintain consistency between the various systems which may be involved in such mapping. Specifically, DNS, DHCP, and ARP. Any application that desires to make use of EUI64 and EUI48 RR's for any other use beyond simple data storage should consider how to resolve at least the following possible inconsistencies in data in the DNS and local network information: 1) A mismatch for the same name where the device referenced by the A and AAAA records do not represent the same device as those referenced by the EUI64 and EUI48 RRs. (E.g. the ARP response for a local IP address does not yield one of the values in an EUI64 or EUI48 RR). 2) A query for a specific name which returns multiple EUI64 and EUI48 records. 3) A query for a specific name which returns only EUI64 and EUI48 records and does not return either of A or AAAA records. >This document provides a specification for a structured way of storing particular data in the DNS. It's not data that can't be stored today using more general RRTypes like TXT. It doesn't advocate publication of anything. What are the privacy concerns? > >If there are concerns that people should take time to understand the privacy implications of publishing subscriber data in the DNS, then that seems entirely valid. But this is not a draft about publishing subscriber data in the DNS, it's a draft about implementing specific RRTypes. > >If there is useful information for the IETF to publish about privacy considerations in the DNS, I don't understand why that should be specific to these particular RRTypes. Are similar privacy concerns not also applicable to the DNS in general? > >I've seen people distribute password hashes and user identities in the DNS before, as a back-end to tacacs servers deployed to authenticate dial-up users. (OK, this is going back a bit.) Surely if there is advice to be given about the publication of subscriber data in the DNS we would want to talk about the general approach, and not specific RRTypes. > >Would we caution people about storing MAC addresses in an EUI48 RR, but not bother to caution other people about storing the same data in TXT records? > >etc, etc. > > >Joe >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From jabley@hopcount.ca Tue Apr 16 06:04:32 2013 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 3053F21F96EB for ; Tue, 16 Apr 2013 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 UPeywZp2ywYU for ; Tue, 16 Apr 2013 06:04:30 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2F16321F96EA for ; Tue, 16 Apr 2013 06:04:30 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id jt11so284175pbb.9 for ; Tue, 16 Apr 2013 06:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=TIsmlMywkldlvicFzTzVfjMLsyqdWGPQTYVaEj1MgkE=; b=XNDWETk/CsWJPIDicqP+rXCVvE6RydAMfKzdYa2RWC7DrZNjO8rxih8R7sbZxKNLKl 1uEnIWGoc9szzswkhkMvsWCq0oCQp1tekMGAfC6zce5+5Z5owqD9LVDmYPWB3a8+ek2E g0q9j0Ogq2qBeGiipY5rLTT0tDJYyQ9IokYfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TIsmlMywkldlvicFzTzVfjMLsyqdWGPQTYVaEj1MgkE=; b=AE83F0qaFvgBkF9jqs8qPvwMcP29elBJ6CAFeXu83UogSnjEaCwHy44UNZcBryUmsO /DHBPksRCESOkbVmYz8IkTWOYijaxjw9y5N1VQ4mUZNuXqnmYay3E4VgbV42waAvH3tc 2ohpvKwe0rneZxTDkQCM0QfhZpmi5wfkEiN821EpZG1yymebMbmLV0IXmAbVHVeTSRiE SMiPoGMNQ0aj5CCnIkY7nqluK7CJ1xm6ZFIkjC0ATjDxC+MXLAY+Si+Y6kKdMAB8tdKw +IoTWpKc3NSjtjjjDIX2mCjiI3Lae5ktDDdHkiVYvPGODubJgz3yl66rjhJ452E4ygy1 asSw== X-Received: by 10.68.78.68 with SMTP id z4mr3010263pbw.161.1366117469953; Tue, 16 Apr 2013 06:04:29 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id ky10sm2588787pab.23.2013.04.16.06.04.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 06:04:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Tue, 16 Apr 2013 09:04:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <32A9F252-3ADB-41C8-A1D6-2CB11E64314B@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> To: Michael StJohns X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkNcFmGLhOPQMyYvneGQcF/pRLPVZ5i4sfk/HGevD6UMntrEaeFldXDbBzclQlQxYshSN8k Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 16 Apr 2013 13:04:32 -0000 Hi Michael, On 2013-04-15, at 18:11, Michael StJohns wrote: > Suggested paragraphs for the security section. >=20 > [ PRIVACY:=20 > There may be privacy concerns with publishing EUI RRs. EUI64 and = EUI48 represent unique identifiers for network connected equipment. As = such, their inclusion within the DNS may result in privacy issues in the = form of unique trackable identities. Unlike the IP addresses and DNS = names for network devices which can and do change over time, the EUI = information will almost always uniquely identify a device (or more = specifically, a network interface). As an example of this, consider a = wireless provider that publishes EUI information for its subscribers. = An entity that wants to relate web queries, for example, to a specific = customer need only do a reverse query from the IP address to a DNS name, = and then a forward query for the EUI information. The tracking entity = may relate all queries to specific unique identities regardless of = changes in IP addresses and DNS names resulting in a possible loss of = privacy for the subscriber.=20 I think this presumes too much about how the EUI48/EUI64 records might = be used. In the use case that triggered this walk in the woods, MAC addresses of = cable modems are published in zones available for query and AXFR by = wholesale customers of the cable company (i.e. ISPs) but are not = generally available to the DNS-querying public. They're protected by = ACLs. They're also published in in-addr.arpa-style zones (but not under = in-addr.arpa), and hence references to forward and reverse queries don't = really mean much. How about something more general, like: "EUI48 and EUI64 addresses are intended to represent unique identifiers = for network-connected equipment. Publishing those identifiers in the DNS = might present privacy concerns, e.g. by providing an indirect mapping = between an IPv4 or IPv6 address and a specific end-user device. = Operators are encouraged to consider the privacy implications of = publishing EUI48 or EUI64 addresses in the DNS before doing so." > Transitive Trust: >=20 > DNSSEC allows the binding of a name to one or more RR's. It is = possible to use DNSSEC to bind both A/AAAA records and EUI64/48 records = to the same name. This should probably not be consider as a secure = binding between an IP address and an EUI64/48 address. {Not sure where = this should go - this gets perilously close to secure ARP and placing = this in the hands of the domain owner rather than the hands of the = network owner is probably a "bad thing" } I'm not entirely sure what problems you are anticipating, here. Can you = elaborate? > Paragraph for the main body: >=20 > [ > EUI64 and EUI48 addresses represent another way of referencing a = network connected host past IP addresses and DNS names. Any system = which deploys EUI64 and EUI48 RR's should consider how to maintain = consistency between the various systems which may be involved in such = mapping. Specifically, DNS, DHCP, and ARP. Any application that = desires to make use of EUI64 and EUI48 RR's for any other use beyond = simple data storage should consider how to resolve at least the = following possible inconsistencies in data in the DNS and local network = information: >=20 > 1) A mismatch for the same name where the device referenced by the A = and AAAA records do not represent the same device as those referenced by = the EUI64 and EUI48 RRs. (E.g. the ARP response for a local IP address = does not yield one of the values in an EUI64 or EUI48 RR). >=20 > 2) A query for a specific name which returns multiple EUI64 and EUI48 = records.=20 >=20 > 3) A query for a specific name which returns only EUI64 and EUI48 = records and does not return either of A or AAAA records. Again, I think you're anticipating a use-case that you haven't = described, here. While mention of the general potential for privacy = violation seems defensible, I don't understand the rationale for = singling out one use-case for examination and dedicating text to it. Surely particular use-cases of EUI48/64 RRs that include potential = problems worth highlighting need to be documented separately, and this = text belongs in those documents. I'll say again that the allocation of code-points to EUI48/EUI64 RRs = doesn't enable any of these use-cases -- they're all possible today, = e.g. using TXT RRs or by encoding MAC addresses into owner names (as = some of the cable companies I mentioned have done). All this = specification does is to provide an opportunity for the encoding and = canonical zone syntax to be more efficient and consistent, respectively. Joe= From chip@2bithacker.net Tue Apr 16 08:01:56 2013 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 EDE1321F96E9 for ; Tue, 16 Apr 2013 08:01:56 -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 0QmRTlDRlNUo for ; Tue, 16 Apr 2013 08:01:56 -0700 (PDT) Received: from mail.2bithacker.net (mail.2bithacker.net [IPv6:2001:470:1f07:202::123]) by ietfa.amsl.com (Postfix) with ESMTP id D102021F93F1 for ; Tue, 16 Apr 2013 08:01:55 -0700 (PDT) Received: from 2bithacker.net (nat-06-mht.dyndns.com [216.146.45.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chip) by mail.2bithacker.net (Postfix) with ESMTPSA id C63572573F; Tue, 16 Apr 2013 11:01:53 -0400 (EDT) Date: Tue, 16 Apr 2013 11:01:54 -0400 From: Chip Marshall To: Michael StJohns Message-ID: <20130416150154.GC65753@2bithacker.net> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <20130415221143.2E57721F93F3@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RIYY1s2vRbPFwWeW" Content-Disposition: inline In-Reply-To: <20130415221143.2E57721F93F3@ietfa.amsl.com> X-OS: Mac OS X 10.8.3 x86_64 up 13 days User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org, dnsops@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chip@2bithacker.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:01:57 -0000 --RIYY1s2vRbPFwWeW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-04-15, Michael StJohns sent: > 1) A mismatch for the same name where the device referenced by > the A and AAAA records do not represent the same device as > those referenced by the EUI64 and EUI48 RRs. (E.g. the ARP > response for a local IP address does not yield one of the > values in an EUI64 or EUI48 RR). This seems unnecessary to me. Is there anything currently implying that A and AAAA records at the same node refer to the same physical machine? If no, is there any reason to expect that the A/AAAA and EUI records refer to the same machine? --=20 Chip Marshall http://2bithacker.net/ --RIYY1s2vRbPFwWeW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlFtZ+IACgkQnTUxIUPEgZ7UowCfQsjlEV9S4Eb30k4ZPDUr1Ogr Yl0An1ZPZReNed8RVHoujquLcYPvka0Q =XJQE -----END PGP SIGNATURE----- --RIYY1s2vRbPFwWeW-- From mstjohns@comcast.net Tue Apr 16 12:56:50 2013 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 53AE921F974C for ; Tue, 16 Apr 2013 12:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 fga8e0AFEUHO for ; Tue, 16 Apr 2013 12:56:49 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 761F621F974F for ; Tue, 16 Apr 2013 12:56:47 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id QaUE1l00D0QuhwU53jwgJ5; Tue, 16 Apr 2013 19:56:40 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta02.westchester.pa.mail.comcast.net with comcast id Qjwe1l00T2kB7pQ3Njwf5U; Tue, 16 Apr 2013 19:56:40 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Apr 2013 15:56:39 -0400 To: chip@2bithacker.net From: Michael StJohns In-Reply-To: <20130416150154.GC65753@2bithacker.net> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <20130415221143.2E57721F93F3@ietfa.amsl.com> <20130416150154.GC65753@2bithacker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366142200; bh=eMH6X6Om3LzF8GhyUjEJOaG3qnCOENbNhyOeG4ewjM8=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=mg1u2AxtrGyWobYCoHsiw4hkWFwuP2BMGl/kmFRq0hzMHdjqR/PRJXyciPbXIIqbU rEeiLRNYDRw7v3QDHul/ex66ItEk2FBzIYkmmM2QqquzU3rrXv+AwoA9eui1yoi6yh +8w5aAn5hWuS10TG2rZe++bMs6xUuBXfoNk/y8SGGOnn6R2R3TtFUS4dIlkBrDYiOY MLvNHXpO7HzUmPhdvuzUZdmj3toTEIBkCj8GMDQWnb7ZPyDfBu8OTcpZ7ZTzXAIR17 rfM3pjQ62T894LDOvx2DakFUorKO2sOd4tGinYFtiqWSQw1ACDv9MCoPDNiI/GtAgu VOZZb+Y/jAu0g== Message-Id: <20130416195647.761F621F974F@ietfa.amsl.com> Cc: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org, dnsops@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 16 Apr 2013 19:56:50 -0000 At 11:01 AM 4/16/2013, Chip Marshall wrote: >On 2013-04-15, Michael StJohns sent: >> 1) A mismatch for the same name where the device referenced by >> the A and AAAA records do not represent the same device as >> those referenced by the EUI64 and EUI48 RRs. (E.g. the ARP >> response for a local IP address does not yield one of the >> values in an EUI64 or EUI48 RR). > >This seems unnecessary to me. Is there anything currently implying >that A and AAAA records at the same node refer to the same >physical machine? If no, is there any reason to expect that the >A/AAAA and EUI records refer to the same machine? IPv4 and v6 addresses are known to move around. I believe there is sufficient documentation to describe what happens if you get the A and AAAA records not referring to the same physical machine (but they generally do refer to the same logical machine - not always, but usually). What the above says is that there isn't documentation for the interaction between A, AAAA and EUI records and there probably needs to be. The EUI records are unique identifiers. My assumption - without any text saying otherwise - is that if I get records with both IP addresses and EUI values that the intent of the domain operator was to convey a relationship between the two. The current document is silent on this intent. It should not be. If this record were just point to random strings of data (e.g. UUIDs for example) that don't have a network related identity, I wouldn't care. But it is EUI48 and 64 addresses that really do have a related network ID. It would be nice if we told applications how to deal with cognitive dissonance of this form. Mike >-- >Chip Marshall >http://2bithacker.net/ > From mstjohns@comcast.net Tue Apr 16 13:15:36 2013 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 6F21621F9777 for ; Tue, 16 Apr 2013 13:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 03e8nnp9fPFP for ; Tue, 16 Apr 2013 13:15:35 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 464F921F9776 for ; Tue, 16 Apr 2013 13:15:35 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id Qb4u1l00E17dt5G53kFarY; Tue, 16 Apr 2013 20:15:34 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta13.westchester.pa.mail.comcast.net with comcast id QkFZ1l01J2kB7pQ3ZkFae0; Tue, 16 Apr 2013 20:15:34 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Apr 2013 16:15:35 -0400 To: Joe Abley From: Michael StJohns In-Reply-To: <32A9F252-3ADB-41C8-A1D6-2CB11E64314B@hopcount.ca> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <32A9F252-3ADB-41C8-A1D6-2CB11E64314B@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366143334; bh=YSOruySL2UpPZpe1e7JzGPw8t2GncGlVMabKYwTZYPk=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=texAE9vvcefZP5bi7uqvhCGuFADDTaeX7nwtWSuUDFj03LYPDCTruO155TTEZv65v n1uq1jmy986UpHI789j4cfuq63O4AcCMFzJHHLqp5tdsj+KA5EWORhbQcknyH9O+pi Cl5npGjBE/fqq2vYjVcxBcZk1/mOaAgfoho6CAev6bnMfB5UvPRd0tdEA/6mrPDjbb qL2KKjWlWZ1EKCdWE3fgPXUSk9/qIZHa/FiZm1VaLNuGgF5IZQ8XADvICpyQ7/d6me dcKvVszA+vEx9RBpMwlKpGr/Ql8OCzXlsIrnbBJLwCBcIwwUT7yw8CnhApOJ13Vvwy kMpDo2f3RRNqA== Message-Id: <20130416201535.464F921F9776@ietfa.amsl.com> Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 16 Apr 2013 20:15:36 -0000 At 09:04 AM 4/16/2013, Joe Abley wrote: >Hi Michael, > >On 2013-04-15, at 18:11, Michael StJohns wrote: > >> Suggested paragraphs for the security section. >> >> [ PRIVACY: >> There may be privacy concerns with publishing EUI RRs. EUI64 and EUI48 represent unique identifiers for network connected equipment. As such, their inclusion within the DNS may result in privacy issues in the form of unique trackable identities. Unlike the IP addresses and DNS names for network devices which can and do change over time, the EUI information will almost always uniquely identify a device (or more specifically, a network interface). As an example of this, consider a wireless provider that publishes EUI information for its subscribers. An entity that wants to relate web queries, for example, to a specific customer need only do a reverse query from the IP address to a DNS name, and then a forward query for the EUI information. The tracking entity may relate all queries to specific unique identities regardless of changes in IP addresses and DNS names resulting in a possible loss of privacy for the subscriber. > >I think this presumes too much about how the EUI48/EUI64 records might be used. > >In the use case that triggered this walk in the woods, MAC addresses of cable modems are published in zones available for query and AXFR by wholesale customers of the cable company (i.e. ISPs) but are not generally available to the DNS-querying public. They're protected by ACLs. They're also published in in-addr.arpa-style zones (but not under in-addr.arpa), and hence references to forward and reverse queries don't really mean much. > >How about something more general, like: > >"EUI48 and EUI64 addresses are intended to represent unique identifiers for network-connected equipment. Publishing those identifiers in the DNS might present privacy concerns, e.g. by providing an indirect mapping between an IPv4 or IPv6 address and a specific end-user device. Operators are encouraged to consider the privacy implications of publishing EUI48 or EUI64 addresses in the DNS before doing so." Until I explained the use case I was concerned about, you mostly didn't think there was a problem. I don't have any problems with the text you propose, but I question whether or not a later reader will get the point or believe there is even an issue. >> Transitive Trust: >> >> DNSSEC allows the binding of a name to one or more RR's. It is possible to use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same name. This should probably not be consider as a secure binding between an IP address and an EUI64/48 address. {Not sure where this should go - this gets perilously close to secure ARP and placing this in the hands of the domain owner rather than the hands of the network owner is probably a "bad thing" } > >I'm not entirely sure what problems you are anticipating, here. Can you elaborate? Sorry. DNSSEC signs a binding between DNS name and A record. DNSSEC signs a binding between DNS name and an EUI record. Application assumes that because there is an Name->A and Name->EUI signed binding, then it can assume a cryptographic binding between the A record (or rather the IP address) and the EUI record (or rather the MAC address). That's probably a bad assumption given that you're not requiring this and should probably be stated in the security section. This particular item came up because someone mentioned that it would be useful to have a signature over the DNS/EUI pairing. >> Paragraph for the main body: >> >> [ >> EUI64 and EUI48 addresses represent another way of referencing a network connected host past IP addresses and DNS names. Any system which deploys EUI64 and EUI48 RR's should consider how to maintain consistency between the various systems which may be involved in such mapping. Specifically, DNS, DHCP, and ARP. Any application that desires to make use of EUI64 and EUI48 RR's for any other use beyond simple data storage should consider how to resolve at least the following possible inconsistencies in data in the DNS and local network information: >> >> 1) A mismatch for the same name where the device referenced by the A and AAAA records do not represent the same device as those referenced by the EUI64 and EUI48 RRs. (E.g. the ARP response for a local IP address does not yield one of the values in an EUI64 or EUI48 RR). >> >> 2) A query for a specific name which returns multiple EUI64 and EUI48 records. >> >> 3) A query for a specific name which returns only EUI64 and EUI48 records and does not return either of A or AAAA records. > >Again, I think you're anticipating a use-case that you haven't described, here. While mention of the general potential for privacy violation seems defensible, I don't understand the rationale for singling out one use-case for examination and dedicating text to it. > >Surely particular use-cases of EUI48/64 RRs that include potential problems worth highlighting need to be documented separately, and this text belongs in those documents. > >I'll say again that the allocation of code-points to EUI48/EUI64 RRs doesn't enable any of these use-cases -- they're all possible today, e.g. using TXT RRs or by encoding MAC addresses into owner names (as some of the cable companies I mentioned have done). All this specification does is to provide an opportunity for the encoding and canonical zone syntax to be more efficient and consistent, respectively. Mostly a TXT record doesn't provide you with globally actionable data and I wouldn't be too worried (or even be able to detect) mismatches between TXT and A records. But you chose to put EUI data in the DNS - you need to think about what that might mean in the future past your simple "throw data in the DNS" application. The fact that the EUI data represents a network connected device in a directly addressable fashion is what makes this more complex than you've considered. I *don't* know what the future uses may be, but I do know that if I start caring about EUI data, I probably want to consider how to deal with mismatches or interactions with A/AAAA data and the EUI data. Consider a draft by Don Eastlake way back in '97 or so dealing with Autonomous System records. It didn't go forward as an RFC, but it did - in its text - consider how the AS data related to other data in the DNS. It went so far to say that A records probably shouldn't go in the same node as AS records. It considered how that record (representing some data that was network actionable) would interact with other records in the DNS. I think you need something like this, or you need to describe a much more constrained usage model than you already have. Later, Mike >Joe From wwwrun@rfc-editor.org Tue Apr 16 16:41:04 2013 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 BBFF221F9768; Tue, 16 Apr 2013 16:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 x13yuD3sWpzI; Tue, 16 Apr 2013 16:41:04 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD521F9757; Tue, 16 Apr 2013 16:41:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 62AD4B1E003; Tue, 16 Apr 2013 16:40:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130416234005.62AD4B1E003@rfc-editor.org> Date: Tue, 16 Apr 2013 16:40:05 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] STD 75, RFC 6891 on Extension Mechanisms for DNS (EDNS(0)) 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, 16 Apr 2013 23:41:04 -0000 A new Request for Comments is now available in online RFC libraries. STD 75 RFC 6891 Title: Extension Mechanisms for DNS (EDNS(0)) Author: J. Damas, M. Graff, P. Vixie Status: Standards Track Stream: IETF Date: April 2013 Mailbox: joao@bondis.org, explorer@flame.org, vixie@isc.org Pages: 16 Characters: 32856 Obsoletes: RFC 2671, RFC 2673 See Also: STD 75 I-D Tag: draft-ietf-dnsext-rfc2671bis-edns0-10.txt URL: http://www.rfc-editor.org/rfc/rfc6891.txt The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document is a product of the DNS Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Tue Apr 16 16:41:31 2013 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 DA73521F97AE; Tue, 16 Apr 2013 16:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 9N0IsQb0FNCz; Tue, 16 Apr 2013 16:41:31 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2721F97A1; Tue, 16 Apr 2013 16:41:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D29F8B1E008; Tue, 16 Apr 2013 16:40:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130416234027.D29F8B1E008@rfc-editor.org> Date: Tue, 16 Apr 2013 16:40:27 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] BCP 42, RFC 6895 on Domain Name System (DNS) 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: Tue, 16 Apr 2013 23:41:32 -0000 A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 6895 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox: d3e3e3@gmail.com Pages: 19 Characters: 38979 Obsoletes: RFC 6195 Updates: RFC 1183, RFC 2845, RFC 2930, RFC 3597 See Also: BCP 42 I-D Tag: draft-ietf-dnsext-rfc6195bis-05.txt URL: http://www.rfc-editor.org/rfc/rfc6895.txt This document specifies Internet Assigned Numbers 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. This document is a product of the DNS Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From pkern@simplex.0x539.de Tue Apr 16 14:16:48 2013 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 B90F221F9790 for ; Tue, 16 Apr 2013 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_15=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 B0NS4PyXSwSC for ; Tue, 16 Apr 2013 14:16:48 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6A21F9788 for ; Tue, 16 Apr 2013 14:16:47 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1USDF5-0003lY-FZ; Tue, 16 Apr 2013 23:16:43 +0200 Received: from [2001:470:720c:0:589:4e0d:8a1a:9b4d] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1USDF6-0002q9-NQ; Tue, 16 Apr 2013 23:16:44 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1USDF5-0004pc-JW; Tue, 16 Apr 2013 23:16:43 +0200 Date: Tue, 16 Apr 2013 23:16:43 +0200 From: Philipp Kern To: Michael StJohns Message-ID: <20130416211643.GC17837@simplex.0x539.de> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <32A9F252-3ADB-41C8-A1D6-2CB11E64314B@hopcount.ca> <20130416201535.464F921F9776@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+" Content-Disposition: inline In-Reply-To: <20130416201535.464F921F9776@ietfa.amsl.com> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 17 Apr 2013 10:38:21 -0700 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 16 Apr 2013 21:16:48 -0000 --ZwgA9U+XZDXt4+m+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael, am Tue, Apr 16, 2013 at 04:15:35PM -0400 hast du folgendes geschrieben: > DNSSEC signs a binding between DNS name and A record. > DNSSEC signs a binding between DNS name and an EUI record. >=20 > Application assumes that because there is an Name->A and Name->EUI signed > binding, then it can assume a cryptographic binding between the A record = (or > rather the IP address) and the EUI record (or rather the MAC address). > That's probably a bad assumption given that you're not requiring this and > should probably be stated in the security section. why should Name->A and Name->EUI imply A<->EUI given that you're querying forward DNS? I don't see how that should be true. I don't think you'd argue the same for {A, MX} or {A, TXT}. One thing where something like this might be relevant is {A, SSHFP}. But I don't think anybody uses DNS->A and DNS->SSHFP together to signify A<->SSHFP, as the matching is on the name. (Obviously in this case it's likely true, but if you'd connect directly to the address you wouldn't get the SSHFP information from anywhere.) > This particular item came up because someone mentioned that it would be > useful to have a signature over the DNS/EUI pairing. A records are another data domain and independent. You can still sign the DNS/EUI mapping. Kind regards Philipp Kern --ZwgA9U+XZDXt4+m+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRbb+7AAoJEERuJUU10Fbso7cH/28XwiBFaIwGtfsxUhtvzPCG 5WpEe1ioFOBYGzxmx+eQLNzkFhEXofbB3qqr6guhn7aomNlZ01q/mShm/vDfAJSz c4pnpw8yQ668KAfbhzRzy2+SPYURaZSzyeV44tuhIrQyg3RzmsqN6Gjp2Up4+ZT1 dc/nz5WafFGTtPWB7Fqe5Q5vjq2CulIHQVvnWQl3hELITOQmgKQ9kwG4CwoALsJJ 8rFBIMdKlbOwlbQ/s1RoArL1iulr1GmvpKGd8/qrFoQD9VaWBPHT/l0VQjjRG4pR EynVkZaBFUDuYp4sPlwAd2tBOQIHW0ya3s6u3GAMHB5UHduGgsv9RC4G9f+0YKA= =crim -----END PGP SIGNATURE----- --ZwgA9U+XZDXt4+m+-- From sm@resistor.net Wed Apr 17 11:13:56 2013 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 45B2021E8054 for ; Wed, 17 Apr 2013 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 E7IzJLk-jEX9 for ; Wed, 17 Apr 2013 11:13:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBDB21E8048 for ; Wed, 17 Apr 2013 11:13:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3HIDn8l023686; Wed, 17 Apr 2013 11:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366222434; bh=oxXQ8vqD9P7MbnN4dsrFObenNcPR72ynCzUOfkN+gt4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g7a90n4WPnTYipUvgabxdTidT4X3XjV25tOXa/cW7zz3yvvDpjfPh4kGZDpoPAOjT GPVRmv7GccF7syNl3LMPgu1vdE9XIqBVU6NWaANfOC3heHcAGmtKK+sg3r/G9Kmt5e s5cQJUR91TcvHksr6hOy05PM1eIoeaQzF8Pj2tq8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366222434; i=@resistor.net; bh=oxXQ8vqD9P7MbnN4dsrFObenNcPR72ynCzUOfkN+gt4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iNbMjemF9vVIwqBc21Wqg04UYX0ZBPLBEDTBs+8asFOnHkU9sl0EBJMNxwADNncpS 0C0GOtOakHCJlMaPq/FJptaZWH0pxvVqi1FWgULP9EcFT7J+IlfaFHXn1c6TCBmW+W E1bJTRQOxD06mS3WnYjzcKjfHR5SE78Yn7txw3nI= Message-Id: <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 17 Apr 2013 11:01:33 -0700 To: Doug Barton From: SM In-Reply-To: <516C346C.5050507@dougbarton.us> References: <516C346C.5050507@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 17 Apr 2013 18:13:56 -0000 Hi Doug, At 10:10 15-04-2013, Doug Barton wrote: >But the mere fact that something is in an RFC doesn't mean that I >have to agree with it carte blanche, does it? Not to mention that >5707 is Informational, so by definition non-canonical. :) It's RFC 5507. It's an IAB document. That doesn't mean that it is has special status. Regards, -sm From dougb@dougbarton.us Wed Apr 17 11:44:38 2013 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 964E021E8047 for ; Wed, 17 Apr 2013 11:44:38 -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 PZfKs0cqxB+1 for ; Wed, 17 Apr 2013 11:44:38 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8621E8042 for ; Wed, 17 Apr 2013 11:44:38 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:3434:7741:fab6:d486] (unknown [IPv6:2001:470:d:5e7:3434:7741:fab6:d486]) by dougbarton.us (Postfix) with ESMTPSA id B09DB22B8D for ; Wed, 17 Apr 2013 18:44:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366224277; bh=fs5kOCOWsFe3EUVbRvWsV6jI5ThbgeaFaGIoliCHcJI=; h=Date:From:To:Subject:References:In-Reply-To; b=q9lsv77w4RbEOeQD7QM5pypzMyr2C+KbKci3p9AMaloSHmC1jgkiS+HfOYIwS32ny dukeNC/hXt3GY3a1ZlPWCBkttEjgN8gV3LAPlRK6HRVmDtE8xtSkanvGJZqaHDmts/ yUxGHRWPZHrkJgJi1Ulb7gG780nw9SQKzW++aT+Q= Message-ID: <516EED94.8010005@dougbarton.us> Date: Wed, 17 Apr 2013 11:44:36 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <516C346C.5050507@dougbarton.us> <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> In-Reply-To: <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 17 Apr 2013 18:44:38 -0000 On 04/17/2013 11:01 AM, SM wrote: > Hi Doug, > At 10:10 15-04-2013, Doug Barton wrote: >> But the mere fact that something is in an RFC doesn't mean that I have >> to agree with it carte blanche, does it? Not to mention that 5707 is >> Informational, so by definition non-canonical. :) > > It's RFC 5507. Yeah, sorry ... if you hadn't snipped so much of my message you would have seen that was clear from context in spite of my typo. > It's an IAB document. That doesn't mean that it is has > special status. so why mention it? :) From d3e3e3@gmail.com Wed Apr 17 12:05:53 2013 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 A00A921F8A00 for ; Wed, 17 Apr 2013 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YvV5hDvKhm7l for ; Wed, 17 Apr 2013 12:05:53 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1821F89E2 for ; Wed, 17 Apr 2013 12:05:52 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1660043obq.3 for ; Wed, 17 Apr 2013 12:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Z42CJznPtwuRwlD6Z0WLbSTqpysXLxKheCqV18PT6jI=; b=Mr43bCT+/lnvTS7Xo2/DDOpM4Y/XWaOj0OwxQS4XNrRuTTezl9g6U3UqTUKygCZwpK 1KPXFLg5mXNQB/5T1ysX22YGj8oSpgfOy3x8F9zlhzNqUe4mHCyoRh7wMOmqEYTIMqXK 6reHHG37t4nXfPK05S5JTNMrWlmkVjkOkt6KTI4V44wmhb2gpoityzzDfaqOOnf9DAa0 ecMBSd3E9dQjmC4aRd37znAVmLHvtVLR3c9HB5s9VrYkKSYpRK7WxnfxHeEGMcBtoetb eXsMkcMN/D8B8D8UHXksZf8zPeq06KUXwuLjFLn8JA74/CYgjY7kCq/SvQ5tqXa4736R XysA== X-Received: by 10.60.146.131 with SMTP id tc3mr3364681oeb.29.1366225552609; Wed, 17 Apr 2013 12:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Wed, 17 Apr 2013 12:05:32 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> References: <516C346C.5050507@dougbarton.us> <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> From: Donald Eastlake Date: Wed, 17 Apr 2013 15:05:32 -0400 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 17 Apr 2013 19:05:53 -0000 I suppose it depends on what you mean by "special" but I believe that informational RFCs issued by the IAB constitute at least a mild form of architectural guidance. To quote from the abstract of 5507: "... This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution." Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Apr 17, 2013 at 2:01 PM, SM wrote: > Hi Doug, > > At 10:10 15-04-2013, Doug Barton wrote: >> >> But the mere fact that something is in an RFC doesn't mean that I have to >> agree with it carte blanche, does it? Not to mention that 5707 is >> Informational, so by definition non-canonical. :) > > > It's RFC 5507. It's an IAB document. That doesn't mean that it is has > special status. > > Regards, > -sm > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From sm@resistor.net Wed Apr 17 12:27:46 2013 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 B75CC21E8064 for ; Wed, 17 Apr 2013 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 2Fni71GtCcYp for ; Wed, 17 Apr 2013 12:27:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D59A621E8047 for ; Wed, 17 Apr 2013 12:27:45 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3HJRcjl010187; Wed, 17 Apr 2013 12:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366226863; bh=l1RSGUl16NqmEQKoZoLYgVIX0s3pdwLq7KSBkypJOSM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IUhHGS88wLoheuFwmEdpvpPHLDEfxFnmi0nbQfrC7D4hwclAcFAswvWnaX6IUBTq1 dL/95nitg9ueXzRxj0eU0LeZwWHDVznHe2mVMajLwbNwJrfNaV4Q2R6UT+bShd5K6/ GRsQzZIIoge1q8Daj/1SL0ky99F/9dsGVTVggIYw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366226863; i=@resistor.net; bh=l1RSGUl16NqmEQKoZoLYgVIX0s3pdwLq7KSBkypJOSM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dxj2T9UXpOT83wfV+jhv04Mc9nVv1bRc/5V5GIr6Ega7CLfIeRH2LzlBZ0k6vMnUc YTekmDuezQP/TqzcA5tEiEg6w5EH0xtNhWIZQhfonJ13nUkZZWiYIw2BTDYsWcycJR H7LJniymerUPswwcUFm2/VuSDTQ1HW8cUTsQbQzc= Message-Id: <6.2.5.6.2.20130417115955.07c7aa70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 17 Apr 2013 12:24:03 -0700 To: Doug Barton From: SM In-Reply-To: <516EED94.8010005@dougbarton.us> References: <516C346C.5050507@dougbarton.us> <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> <516EED94.8010005@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 17 Apr 2013 19:27:47 -0000 Hi Doug, At 11:44 17-04-2013, Doug Barton wrote: >Yeah, sorry ... if you hadn't snipped so much of my message you >would have seen that was clear from context in spite of my typo. I saw the correct link. I looked up the (typo) RFC and wondered how it was related to DNS. >so why mention it? :) It's because I will be reading that RFC in future and I may use if I comment about the draft. Regards, -sm From dougb@dougbarton.us Wed Apr 17 21:42:54 2013 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 1F7CA21F8233 for ; Wed, 17 Apr 2013 21:42:53 -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 R+rwEY16JMMe for ; Wed, 17 Apr 2013 21:42:25 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8211E80A3 for ; Wed, 17 Apr 2013 21:42:24 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:9568:88a3:292d:ef8] (unknown [IPv6:2001:470:d:5e7:9568:88a3:292d:ef8]) by dougbarton.us (Postfix) with ESMTPSA id 8E15522C1D for ; Thu, 18 Apr 2013 04:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366260144; bh=TviTW0FzYTw5solnGg06OQDCGihUCh0SjXKJXnnUmD4=; h=Date:From:To:Subject:References:In-Reply-To; b=PUkFwYfZP0oZDIWcXnkWPxPhUINkCzCgUacEtGjck1vc0aZFWEpj2x9aoEJzBDUpV XXQc5OgsnMhJeHtTcveRRbB1Y/dN0XQH5KnIurFmbjsfJPL8Gf+5dHd2s5wH4F4lUc T8eRyqBQLFd7bkUUBe/YD/f1FuPhiuXpqmG42rlo= Message-ID: <516F79B0.2060508@dougbarton.us> Date: Wed, 17 Apr 2013 21:42:24 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dnsext@ietf.org" References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516C2DFA.20809@dougbarton.us> <0BC57CBA-552B-4DC6-A7B7-123A58112E16@hopcount.ca> In-Reply-To: <0BC57CBA-552B-4DC6-A7B7-123A58112E16@hopcount.ca> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 04:42:54 -0000 On 04/15/2013 10:20 AM, Joe Abley wrote: > On 2013-04-15, at 12:42, Doug Barton wrote: > >> On 04/15/2013 09:18 AM, Joe Abley wrote: >>> >>> On 2013-04-15, at 12:10, Doug Barton >>> wrote: >>> >>>> It's not at all clear why the right answer isn't a common >>>> definition of how to do this in a TXT record. Not everything >>>> needs (or should have) it's own RRtype. >>> >>> I think this is madness. >>> >>> By this logic we didn't need to bother defining AAAA records, >>> since there's no reason why they can't live in TXT records. Ditto >>> DNSKEY, and everything, really. Why even have RRTypes, if we can >>> just ship free-form text around? >> >> Don't be absurd. You're smart enough to know the difference between >> something that is widely or near-universally deployed, > > ... like ethernet... And every ethernet port is going to have one of your new records in DNS? C'mon Joe, argue for your positions merits, sure. But please stop using these ad absurdum claims, it doesn't add anything to the discourse. >> and something that is a special case for a limited number of >> environments > > ... like DNSSEC or IPv6 when AAAA and DNSKEY were assigned, or, even > arguably, now? Each of your examples above were planned for wide deployment, and the use cases were obvious from the beginning. It's still not clear to me how wide spread the use case is for these records, but apparently that doesn't matter since the ship has sailed. That's not hurting anything, as was pointed out the potential space is huge, and we're only using a tiny fraction of it. Just like IPv4. Oh, wait ... :) >> ; and the relative value of exhausting a scarce resource for each. >> >> Or is your argument that everyone who applies should get an RR code >> point, until they're all gone? > > I certainly don't think we should be turning down RRType applications > on the grounds that one day we might possibly run out of code points. > By that logic, we'd never assign any at all. Again, ad absurdum. My point was that there should be _some_ criteria applied regarding how "popular" (to use a crass and loaded term) a new record is likely to be. Or, I could be wrong ... and my concern is totally misplaced. Either way I find it fascinating that people are not willing to even consider the question. > Fortunately, the question at hand is not whether you think assignment > is a good idea (code points have already been assigned) or whether > this is something you would ever use (feel free not to). The question > is whether the document provides reasonable documentation that could > facilitate implementation and interop. Do you have any opinions on > that? Dunno, I still haven't gotten past how silly I think the idea is. :) Meanwhile, there are plenty of people who have made observations about the utility of your draft, I'm sure it will get whipped into shape with or without me. >> FWIW, we did something similar when I was at Yahoo!, and I know >> from experience that TXT works just fine for this purpose. > > I had no idea Yahoo! was involved with implementing CRTC policy > decades before it was enacted, that's certainly impressive. Well now you're just being an ass. I think my meaning was clear, if you're interested in hearing about our use case I'm happy to share, if you're not, that's fine too. >> As I said in my first message, I am not opposed to assigning >> RRtypes for this per se, but I don't think that the use case is >> well enough documented to justify it yet. > > Noted, but your opinion (or anybody else's) on these assignments is > not actually relevant here. Thanks for making your perspective clear. :) Doug From jim@rfc1035.com Thu Apr 18 02:18:03 2013 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 03E7D21F8F32 for ; Thu, 18 Apr 2013 02:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 UnJmztMR1HVW for ; Thu, 18 Apr 2013 02:18:00 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 788E121F8F0A for ; Thu, 18 Apr 2013 02:18:00 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 953B0CBC41F; Thu, 18 Apr 2013 10:17:59 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <516C346C.5050507@dougbarton.us> Date: Thu, 18 Apr 2013 10:17:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <263E8ED9-DFB7-4DF9-8BD0-444B2A59006D@rfc1035.com> References: <516C346C.5050507@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: [dnsext] type code assignments and draft-jabley-dnsext-eui48-eui64-rrtypes 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, 18 Apr 2013 09:18:03 -0000 On 15 Apr 2013, at 18:10, Doug Barton wrote: > But the mere fact that something is in an RFC doesn't mean that I have = to agree with it carte blanche, does it? Doug, you're being silly and not contributing anything useful or = constructive to the discussion. Please stop. Whether you like some RFC or not is your choice. Nobody else cares or = needs to care about your RFC preferences. Just like the world doesn't = need to do that for mine. You've said on this thread that you consider the draft does not justify = the assignment of type codes. But not why you think that. No, don't = bother: the time where that opinion may have counted or was even worth = listening to has long passed. The expert reviewers have decided the idea = is sound and justify the type code assignments which IANA has duly done. = Their opinion is the one which matters here. They've spoken. We're done. = This thread should have stopped long ago. In an earlier posting you asked "is your argument that everyone who = applies should get an RR code point, until they're all gone?". Well the = short answer to that is yes. Read RFC6195. The expert reviewers can and = should be trusted to block frivolous or badly thought out type code = assignment requests. That's why they're expert reviewers. If they screw = up or somehow lose the confidence of the WG, they get replaced. The point of the lightweight type code assignment mechanism is to avoid = futile angels on pinheads debates in this list. PS At current assigment rates, the Internet will run out of RR type = codes a few thousand years from now. If this rate changes dramatically, = I'm reasonably certain a viable solution will be available in good time: = say a 128 bit QTYPE2 field in EDNS8 queries.=20 From ajs@anvilwalrusden.com Thu Apr 18 06:27:27 2013 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 BDBC121F8E67 for ; Thu, 18 Apr 2013 06:27:27 -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 OCVwx1a7Vxt4 for ; Thu, 18 Apr 2013 06:27:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 78D2D21F8E5E for ; Thu, 18 Apr 2013 06:27:26 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BBCF78A031 for ; Thu, 18 Apr 2013 13:27:25 +0000 (UTC) Date: Thu, 18 Apr 2013 09:27:25 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130418132724.GC12426@mx1.yitter.info> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516C2DFA.20809@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516C2DFA.20809@dougbarton.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 13:27:27 -0000 Dear colleagues, No hat. On Mon, Apr 15, 2013 at 09:42:34AM -0700, Doug Barton wrote: > Or is your argument that everyone who applies should get an RR code > point, until they're all gone? The WG already came to consensus on the answer to that question. It was, roughly, "Yes." The guidelines for this are well-specified, and therefore arguments to the effect that a particular use case is not good enough for a typecode assignment have no force. Moreover, I think this is a good thing. There are a lot of people around the DNS community who seem to think we have a responsibility to be the protocol cops. I am not one of them. I think that it should be cheap and easy to get a typecode assignment at least until we start to see evidence that the number space is getting used up unsustainably quickly. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From thierry.moreau@connotech.com Thu Apr 18 06:47:11 2013 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 1A5AC21F8F07 for ; Thu, 18 Apr 2013 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s3VqI717Srs for ; Thu, 18 Apr 2013 06:47:10 -0700 (PDT) Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9921F8ED3 for ; Thu, 18 Apr 2013 06:47:00 -0700 (PDT) Received: from [192.168.1.200] (PORTABLE-THIERRY.CONNOTECH-INTERNAL.COM [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id 51455317CB; Thu, 18 Apr 2013 09:47:00 -0400 (EDT) Message-ID: <516FF953.1010108@connotech.com> Date: Thu, 18 Apr 2013 09:46:59 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Joe Abley References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 13:47:11 -0000 Joe Abley wrote: > On 2013-04-15, at 12:10, Doug Barton wrote: > >> It's also not clear why IANA has already assigned code points for this (as described in your text). > > Because the expert review passed, and IANA was following the required procedure, I think. > [reviewing the discussion from a process perspective -- what is the root cause of the controversy?] It appears that the bar for RR type allocation is lower than for an informational RFC. To which extent should the IESG lower the bar for a specific I-D on the ground that it acquired an RR type? Incidentally: Process-wise, we could be in front of a "submarine RFC" case: IANA (or the expert?) would have followed the RFC6895 procedures before it was published. It bugs me that the IANA allocation process uses a mailing list a) not listed in the IANA web pages, and b) (I guess) subject to the IETF IPR disclosure policy by virtue of being run under the ietf.org domain. I am not particularly expert in those details, but somehow I care that 1) stakeholders are created equal, but some are more equal than others (e.g. those aware in advance of the submarine RFC), and 2) who controls the process controls the outcome. Regards, - Thierry Moreau From jabley@hopcount.ca Thu Apr 18 07:16:10 2013 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 3EFEF21F8EBF for ; Thu, 18 Apr 2013 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 G0ZMb5NnXLsx for ; Thu, 18 Apr 2013 07:16:09 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEC621F8F02 for ; Thu, 18 Apr 2013 07:16:09 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so1715161qeb.34 for ; Thu, 18 Apr 2013 07:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=JyL4ZBRNXv63fFZof619Up4VFaGISQMXWn8HRKRjJto=; b=fBqX5cVXF0EDtlPzEhRT9uD+qxy6zlKjoyrFJ3zE/tnc9gSyRkB8NUty+JbL5dmiBL sgeZwiHpZuP+dQgtYq9TfNMw9jFiNJZWDgiY3MBujKw4TtpR3T7w2QsT8hUYMrDuhLzM b6vXD1EbCLQDBMigQzE4aC0lySvk5v7QJ402g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JyL4ZBRNXv63fFZof619Up4VFaGISQMXWn8HRKRjJto=; b=jpJ0ZzLDrqusJ8ma4veQxh/Mokds4Uc8uOYU2GkqfpsHXuGVAXzinz0/zdW0fldTwT LRPocTVqYJ576mE6SxKMDueqPOH0o9B9rmEsp9OODoH7Gm7tCzo1SHqWKROimEDsWUMk NmITs0Wo/lp3oYxjGfVqUm+Ht3yxbJRjvI0jlQJDwDw2LVMUNMwALrFBG4g7BK43PCZM EwRfYp0S0N5i2CwOO5dgOW00UcKYySdvXgOy+ML6NELeofzM9D6EWLfgGaQ06oRpA2/W F15XFqcNpkA0Wu45LmTgiLTJfoAZZ5oKZIa6z6iMThriyZIhv9C8QJIlFa4ue/JMiMbc Zjhg== X-Received: by 10.224.17.72 with SMTP id r8mr10501461qaa.48.1366294568752; Thu, 18 Apr 2013 07:16:08 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:18eb:1cb9:572d:3d5e? ([2001:4900:1042:100:18eb:1cb9:572d:3d5e]) by mx.google.com with ESMTPS id en8sm12275042qeb.0.2013.04.18.07.16.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 07:16:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <516FF953.1010108@connotech.com> Date: Thu, 18 Apr 2013 10:16:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516FF953.1010108@connotech.com> To: Thierry Moreau X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlME1XlkOpf8V6o/wKDuC41HmaLW1xfhpdFiB0vKqa+Yo4FU0cEtDkDum3FozOg3k3FlraR Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 14:16:10 -0000 On 2013-04-18, at 09:46, Thierry Moreau = wrote: > Joe Abley wrote: >> On 2013-04-15, at 12:10, Doug Barton wrote: >>> It's also not clear why IANA has already assigned code points for = this (as described in your text). >> Because the expert review passed, and IANA was following the required = procedure, I think. >=20 > [reviewing the discussion from a process perspective -- what is the = root cause of the controversy?] >=20 > It appears that the bar for RR type allocation is lower than for an = informational RFC. The RRType application registry's bar is "expert review". The bar for = publication of an informational RFC depends on what stream you follow, = whether it's a working group document, etc. It's not clear to me that = one bar is obviously lower; they're just different. > To which extent should the IESG lower the bar for a specific I-D on = the ground that it acquired an RR type? I'm not sure that it should (nor that anybody has suggested it should, = or would). > Incidentally: >=20 > Process-wise, we could be in front of a "submarine RFC" case: IANA (or = the expert?) would have followed the RFC6895 procedures before it was = published. As I understand it, the directions in draft-ietf-dnsext-rfc6195bis-05 = were followed by the IANA once that document was approved by the IESG. = It looks like that happened in December last year. The document emerged = from the RFC editor queue as RFC6895 two days ago. It doesn't seem unreasonable that "IESG approval" is the trigger here, = rather than "RFC published". > It bugs me that the IANA allocation process uses a mailing list a) not = listed in the IANA web pages, and b) (I guess) subject to the IETF IPR = disclosure policy by virtue of being run under the ietf.org domain. I'm not sure what mailing list you're talking about. Applications for = RRTYPE code point assignments are sent to = dns-rrtype-applications@ietf.org, which seems to forward to a ticket = system at the IANA. > I am not particularly expert in those details, but somehow I care that > 1) stakeholders are created equal, but some are more equal than others = (e.g. those aware in advance of the submarine RFC), and I had no particular awareness of the process when I applied for code = points for EUI48 and EUI64 -- I just found the relevant registry at = www.iana.org and clicked the link above the table. That took me to = draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I followed = them. > 2) who controls the process controls the outcome. My experience with this application was that the process was efficient, = easy to find and easy to understand. Joe= From d3e3e3@gmail.com Thu Apr 18 10:56:21 2013 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 AB0A021F9020 for ; Thu, 18 Apr 2013 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VxBEtRvEI9fy for ; Thu, 18 Apr 2013 10:56:12 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 87CE121F86E8 for ; Thu, 18 Apr 2013 10:56:11 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wd20so2701785obb.7 for ; Thu, 18 Apr 2013 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=C30ju0A/GMzOPQBc2jQmDGZLsJ4mAYYLpm4gjk7JoXI=; b=NVC4kP0Ncgok6ofoL6Z6x6+j6JtUBfULffPb8LDslDO2LvygcOAaM1ojjpB6A1ia/f ZFO9mEv5Ej/ql6sE/iYYCHWUNv0hD0xbEXfCww7bjWkOKg51rIz+eKgAip/57z6HCSvL Bt4xmkU77sHQ2pDuJ1tHl2mHg1MEfmXFJIInFv8mlEBR1yYZGuJSDQ8UKN6Ke09bhWjr ZIH3kA0rzdDlZ1PqaxaorSmFYEpAjvoAwrmC3KUcGM2uU5YxLt8Csqa/QND1KW5k13On avck4lbt3svGJe3b1/zp9eqgV5mv/Djm4iACx2uCc0ILg0byN6GALj8BzcIS6Nu/HxkT Ln+w== X-Received: by 10.60.23.70 with SMTP id k6mr6055996oef.90.1366307761077; Thu, 18 Apr 2013 10:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Thu, 18 Apr 2013 10:55:41 -0700 (PDT) In-Reply-To: References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516FF953.1010108@connotech.com> From: Donald Eastlake Date: Thu, 18 Apr 2013 13:55:41 -0400 Message-ID: To: Thierry Moreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DNSEXT WG Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 17:56:21 -0000 Hi Thierry, Calling anything but April 1st RFCs a "submarine RFC" is pretty silly. (April 1st RFCs really do appear with no warning.) They are all internet-drafts first and publicly available there even before they are listed in the RFC Edtior's queue for, usually, a couple of months, while going through the editing process. And, in the case of a WG document like rfc6195bis, there is notice and discussion in the working group, the IETF Last Call, the IESG process tracked in the datatracker, etc. The IESG has the standards setting and BCP approval authority in the IETF. It has always been the case that, unless perhaps there is some special provision in the document, drafts take effect on the final approval by the IESG, that is, at the time they are transferred to the RFC Editor, not when the RFC issues. RFC Editor's queue is here, which is linked off the RFC Editor home page: http://www.rfc-editor.org/queue2.html RFC publication can be held up for a variety of reasons. The oldest document currently in the queue was placed there 2012-02-21, almost 14 months ago. 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 On Thu, Apr 18, 2013 at 10:16 AM, Joe Abley wrote: > > On 2013-04-18, at 09:46, Thierry Moreau wr= ote: > >> Joe Abley wrote: >>> On 2013-04-15, at 12:10, Doug Barton wrote: >>>> It's also not clear why IANA has already assigned code points for this= (as described in your text). >>> Because the expert review passed, and IANA was following the required p= rocedure, I think. >> >> [reviewing the discussion from a process perspective -- what is the root= cause of the controversy?] >> >> It appears that the bar for RR type allocation is lower than for an info= rmational RFC. > > The RRType application registry's bar is "expert review". The bar for pub= lication of an informational RFC depends on what stream you follow, whether= it's a working group document, etc. It's not clear to me that one bar is o= bviously lower; they're just different. > >> To which extent should the IESG lower the bar for a specific I-D on the = ground that it acquired an RR type? > > I'm not sure that it should (nor that anybody has suggested it should, or= would). > >> Incidentally: >> >> Process-wise, we could be in front of a "submarine RFC" case: IANA (or t= he expert?) would have followed the RFC6895 procedures before it was publis= hed. > > As I understand it, the directions in draft-ietf-dnsext-rfc6195bis-05 wer= e followed by the IANA once that document was approved by the IESG. It look= s like that happened in December last year. The document emerged from the R= FC editor queue as RFC6895 two days ago. > > It doesn't seem unreasonable that "IESG approval" is the trigger here, ra= ther than "RFC published". > >> It bugs me that the IANA allocation process uses a mailing list a) not l= isted in the IANA web pages, and b) (I guess) subject to the IETF IPR discl= osure policy by virtue of being run under the ietf.org domain. > > I'm not sure what mailing list you're talking about. Applications for RRT= YPE code point assignments are sent to dns-rrtype-applications@ietf.org, wh= ich seems to forward to a ticket system at the IANA. > >> I am not particularly expert in those details, but somehow I care that >> 1) stakeholders are created equal, but some are more equal than others (= e.g. those aware in advance of the submarine RFC), and > > I had no particular awareness of the process when I applied for code poin= ts for EUI48 and EUI64 -- I just found the relevant registry at www.iana.or= g and clicked the link above the table. That took me to draft-ietf-dnsext-r= fc6195bis-05 which contained instructions; I followed them. > >> 2) who controls the process controls the outcome. > > My experience with this application was that the process was efficient, e= asy to find and easy to understand. > > > Joe > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From thierry.moreau@connotech.com Thu Apr 18 11:41:30 2013 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 9C16F21F90B4 for ; Thu, 18 Apr 2013 11:41:30 -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 plJ+KpeXou3V for ; Thu, 18 Apr 2013 11:41:29 -0700 (PDT) Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 356BE21F8D5F for ; Thu, 18 Apr 2013 11:41:29 -0700 (PDT) Received: from [192.168.1.200] (PORTABLE-THIERRY.CONNOTECH-INTERNAL.COM [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id D084D3178A; Thu, 18 Apr 2013 14:41:28 -0400 (EDT) Message-ID: <51703E58.90300@connotech.com> Date: Thu, 18 Apr 2013 14:41:28 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Donald Eastlake References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516FF953.1010108@connotech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DNSEXT WG Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 18:41:30 -0000 Donald Eastlake wrote: > Hi Thierry, > > Calling anything but April 1st RFCs a "submarine RFC" is pretty silly. > (April 1st RFCs really do appear with no warning.) > I stand corrected on this one, with the following nuance: while IETF processes are eminently transparent and public, they remain obscure and complex, at least at the detailed level, for anyone not directly involved. I stand corrected because IANA web pages indeed refers to the I-D once approved and until the RFC is published (but still, once the RFC is published, the date of I-D approval disappears from the IANA web pages ... so a hindsight understanding of IANA motivation for a protocol assignment between I-D approval and RFC publication is harder). > They are all internet-drafts first and publicly available there even > before they are listed in the RFC Edtior's queue for, usually, a > couple of months, while going through the editing process. And, in the > case of a WG document like rfc6195bis, there is notice and discussion > in the working group, the IETF Last Call, the IESG process tracked in > the datatracker, etc. > > The IESG has the standards setting and BCP approval authority in the > IETF. It has always been the case that, unless perhaps there is some > special provision in the document, drafts take effect on the final > approval by the IESG, that is, at the time they are transferred to the > RFC Editor, not when the RFC issues. > I never figured out how to train myself about BCP. I got bored of IETF process before I could. So what about others not directly involved? > RFC Editor's queue is here, which is linked off the RFC Editor home page: > http://www.rfc-editor.org/queue2.html > RFC publication can be held up for a variety of reasons. The oldest > document currently in the queue was placed there 2012-02-21, almost 14 > months ago. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Thu, Apr 18, 2013 at 10:16 AM, Joe Abley wrote: >> On 2013-04-18, at 09:46, Thierry Moreau wrote: >> >>> Joe Abley wrote: >>>> On 2013-04-15, at 12:10, Doug Barton wrote: >>>>> It's also not clear why IANA has already assigned code points for this (as described in your text). >>>> Because the expert review passed, and IANA was following the required procedure, I think. >>> [reviewing the discussion from a process perspective -- what is the root cause of the controversy?] >>> >>> It appears that the bar for RR type allocation is lower than for an informational RFC. >> The RRType application registry's bar is "expert review". The bar for publication of an informational RFC depends on what stream you follow, whether it's a working group document, etc. It's not clear to me that one bar is obviously lower; they're just different. >> >>> To which extent should the IESG lower the bar for a specific I-D on the ground that it acquired an RR type? >> I'm not sure that it should (nor that anybody has suggested it should, or would). >> >>> Incidentally: >>> >>> Process-wise, we could be in front of a "submarine RFC" case: IANA (or the expert?) would have followed the RFC6895 procedures before it was published. >> As I understand it, the directions in draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that document was approved by the IESG. It looks like that happened in December last year. The document emerged from the RFC editor queue as RFC6895 two days ago. >> >> It doesn't seem unreasonable that "IESG approval" is the trigger here, rather than "RFC published". >> >>> It bugs me that the IANA allocation process uses a mailing list a) not listed in the IANA web pages, and b) (I guess) subject to the IETF IPR disclosure policy by virtue of being run under the ietf.org domain. >> I'm not sure what mailing list you're talking about. Applications for RRTYPE code point assignments are sent to dns-rrtype-applications@ietf.org, which seems to forward to a ticket system at the IANA. >> >>> I am not particularly expert in those details, but somehow I care that >>> 1) stakeholders are created equal, but some are more equal than others (e.g. those aware in advance of the submarine RFC), and >> I had no particular awareness of the process when I applied for code points for EUI48 and EUI64 -- I just found the relevant registry at www.iana.org and clicked the link above the table. That took me to draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I followed them. >> >>> 2) who controls the process controls the outcome. >> My experience with this application was that the process was efficient, easy to find and easy to understand. >> >> >> Joe >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From joelja@bogus.com Thu Apr 18 11:47:41 2013 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 87B3221E803C for ; Thu, 18 Apr 2013 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 U79UXZV9K6hp for ; Thu, 18 Apr 2013 11:47:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1D21E8039 for ; Thu, 18 Apr 2013 11:47:40 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3IIlakW001018 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Apr 2013 18:47:36 GMT (envelope-from joelja@bogus.com) Message-ID: <51703FC3.6010604@bogus.com> Date: Thu, 18 Apr 2013 11:47:31 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Thierry Moreau , Donald Eastlake References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <516FF953.1010108@connotech.com> <51703E58.90300@connotech.com> In-Reply-To: <51703E58.90300@connotech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 18 Apr 2013 18:47:36 +0000 (UTC) Cc: IETF DNSEXT WG Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 18 Apr 2013 18:47:41 -0000 On 4/18/13 11:41 AM, Thierry Moreau wrote: > Donald Eastlake wrote: >> Hi Thierry, >> >> Calling anything but April 1st RFCs a "submarine RFC" is pretty silly. >> (April 1st RFCs really do appear with no warning.) >> > > I stand corrected on this one, with the following nuance: while IETF > processes are eminently transparent and public, they remain obscure > and complex, at least at the detailed level, for anyone not directly > involved. > > I stand corrected because IANA web pages indeed refers to the I-D once > approved and until the RFC is published (but still, once the RFC is > published, the date of I-D approval disappears from the IANA web pages > ... so a hindsight understanding of IANA motivation for a protocol > assignment between I-D approval and RFC publication is harder). Were this AD sponsored, which in fact it isn't yet the responsible AD would be looking for reviewers, and at a minimum it would be subject to an IETF last call. the ISG processing rules say: AD Sponsored documents to Standards Track require review in the IETF, IETF Last Call, and IESG approval. AD Sponsored documents to Experimental/Informational require some form of review in the IETF and IESG approval. While RFC 2026 does not require the latter type of documents to go through an IETF Last Call, this statement suggests that it is always performed. It is needed to ensure adequate review and transparency in a situation where the pending publication of the document may not be known by any Working Group or the IETF community at large. >> They are all internet-drafts first and publicly available there even >> before they are listed in the RFC Edtior's queue for, usually, a >> couple of months, while going through the editing process. And, in the >> case of a WG document like rfc6195bis, there is notice and discussion >> in the working group, the IETF Last Call, the IESG process tracked in >> the datatracker, etc. >> >> The IESG has the standards setting and BCP approval authority in the >> IETF. It has always been the case that, unless perhaps there is some >> special provision in the document, drafts take effect on the final >> approval by the IESG, that is, at the time they are transferred to the >> RFC Editor, not when the RFC issues. >> > > I never figured out how to train myself about BCP. I got bored of IETF > process before I could. So what about others not directly involved? > >> RFC Editor's queue is here, which is linked off the RFC Editor home >> page: >> http://www.rfc-editor.org/queue2.html >> RFC publication can be held up for a variety of reasons. The oldest >> document currently in the queue was placed there 2012-02-21, almost 14 >> months ago. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> On Thu, Apr 18, 2013 at 10:16 AM, Joe Abley wrote: >>> On 2013-04-18, at 09:46, Thierry Moreau >>> wrote: >>> >>>> Joe Abley wrote: >>>>> On 2013-04-15, at 12:10, Doug Barton wrote: >>>>>> It's also not clear why IANA has already assigned code points for >>>>>> this (as described in your text). >>>>> Because the expert review passed, and IANA was following the >>>>> required procedure, I think. >>>> [reviewing the discussion from a process perspective -- what is the >>>> root cause of the controversy?] >>>> >>>> It appears that the bar for RR type allocation is lower than for an >>>> informational RFC. >>> The RRType application registry's bar is "expert review". The bar >>> for publication of an informational RFC depends on what stream you >>> follow, whether it's a working group document, etc. It's not clear >>> to me that one bar is obviously lower; they're just different. >>> >>>> To which extent should the IESG lower the bar for a specific I-D on >>>> the ground that it acquired an RR type? >>> I'm not sure that it should (nor that anybody has suggested it >>> should, or would). >>> >>>> Incidentally: >>>> >>>> Process-wise, we could be in front of a "submarine RFC" case: IANA >>>> (or the expert?) would have followed the RFC6895 procedures before >>>> it was published. >>> As I understand it, the directions in >>> draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that >>> document was approved by the IESG. It looks like that happened in >>> December last year. The document emerged from the RFC editor queue >>> as RFC6895 two days ago. >>> >>> It doesn't seem unreasonable that "IESG approval" is the trigger >>> here, rather than "RFC published". >>> >>>> It bugs me that the IANA allocation process uses a mailing list a) >>>> not listed in the IANA web pages, and b) (I guess) subject to the >>>> IETF IPR disclosure policy by virtue of being run under the >>>> ietf.org domain. >>> I'm not sure what mailing list you're talking about. Applications >>> for RRTYPE code point assignments are sent to >>> dns-rrtype-applications@ietf.org, which seems to forward to a ticket >>> system at the IANA. >>> >>>> I am not particularly expert in those details, but somehow I care that >>>> 1) stakeholders are created equal, but some are more equal than >>>> others (e.g. those aware in advance of the submarine RFC), and >>> I had no particular awareness of the process when I applied for code >>> points for EUI48 and EUI64 -- I just found the relevant registry at >>> www.iana.org and clicked the link above the table. That took me to >>> draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I >>> followed them. >>> >>>> 2) who controls the process controls the outcome. >>> My experience with this application was that the process was >>> efficient, easy to find and easy to understand. >>> >>> >>> Joe >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >> > > From mohta@necom830.hpcl.titech.ac.jp Fri Apr 19 00:02:53 2013 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 E3F3221F9301 for ; Fri, 19 Apr 2013 00:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 czPkr3YmdsAX for ; Fri, 19 Apr 2013 00:02:53 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 2AD1521F92C4 for ; Fri, 19 Apr 2013 00:02:48 -0700 (PDT) Received: (qmail 5127 invoked from network); 19 Apr 2013 07:00:28 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 19 Apr 2013 07:00:28 -0000 Message-ID: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Apr 2013 16:01:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 19 Apr 2013 07:02:54 -0000 Maybe, most of you are uninterested in technical content of the draft. But, the proposal not using just an EUI type (depends on RDLENGTH), but EUI48 and EUI64 types is inefficient w.r.t. RR type space and the number of queries to get EUI information of a node. Masataka Ohta From jabley@hopcount.ca Fri Apr 19 07:04:55 2013 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 E783C21F8766 for ; Fri, 19 Apr 2013 07:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y0qRETwt1XUk for ; Fri, 19 Apr 2013 07:04:55 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D786E21F8619 for ; Fri, 19 Apr 2013 07:04:54 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 11so3593454vbe.19 for ; Fri, 19 Apr 2013 07:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UhgTLKvvohTJ+nUkmLo39L8BP6o1Ob4th8uv/KMRtdI=; b=VjqQFLwGrmiIuMIESic0UyF1ypR01hJYDejhQjreUgzW6p1Q8dwiGm0v4PakZyFamT 7rGh4SZtgaWNFsWCymWj0D2jj//5HLYZQtF5lwgBv1OmLf9qbMGtBxeB5C79q8HmIwxY YVlkSXHF6dfTxNO8/7MCjP9OhNCDQszW8tdaY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UhgTLKvvohTJ+nUkmLo39L8BP6o1Ob4th8uv/KMRtdI=; b=B+ST0KUBkPdqCP9lJwNcNykQKCb64qp3dUPCWRXh/Y6X0O6OW883gwnAQBsHZ1LJji T7JhW4+mh+mpKoIGFRKvtJJ3+q9Tajd8Xb9HAXyeM2vbJU7It7WrKerr6b+11pyNFgmg qv8bNNPbmMdaaUCj2hOE75hk2fPpp/tQx436UIsb+bWaFMx43+KRPvUhgm9L9jAyV9GJ Sv+1vVlV2igQfKZMOl7LWDYr4eYu4hrbQ3e1sx6CYkvjPNJ6ghQZofb+G7nZGoe1FcOm DA9vHVlMmyz0QBshRdSDktamhdigv2/NLghZQfSzUqgMjEbHOs80g8P2umOF41z5TL62 r0GQ== X-Received: by 10.220.209.135 with SMTP id gg7mr11754117vcb.28.1366380294248; Fri, 19 Apr 2013 07:04:54 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:89d8:3212:c5b8:e25d? ([2001:4900:1042:100:89d8:3212:c5b8:e25d]) by mx.google.com with ESMTPS id a17sm14007847vdj.2.2013.04.19.07.04.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 07:04:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Apr 2013 10:04:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkeNC+BHgOZsIPljIggqNDWR/XTRC8jwiInRn2hDtNri+kUlLW7tllGg4dm+P9VmxDP6Mu5 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 19 Apr 2013 14:04:56 -0000 Ohta-san, On 2013-04-19, at 03:01, Masataka Ohta = wrote: > Maybe, most of you are uninterested in technical content of > the draft. >=20 > But, the proposal not using just an EUI type (depends on RDLENGTH), > but EUI48 and EUI64 types is inefficient w.r.t. RR type space > and the number of queries to get EUI information of a node. It sounds like your counter-proposal would have been to specify a single = RRType with an additional field in the RDATA to distinguish between = EUI48 and EUI64, e.g. without drawing the bitfields, something that = might have a presentation format like owner1.example. 86400 IN EUI 48 7c-d1-c3-e8-10-2f I think that's a perfectly valid idea. However, two code points have = already been assigned for each of EUI48 and EUI64 at this point, and at = least one vendor has implemented them according to the = currently-circulating specification. I think we can consider both = assigned code points to be polluted at this point, and hence revising = the spec to make use of a single RRType would (a) not actually preserve = a code point in the RRTypes registry, and (b) would present interop = problems against current implementations if one of the assigned = code-points was re-used. In effect, to implement your suggestion would = require a third code-point. Joe= From bdickson@verisign.com Fri Apr 19 08:22:38 2013 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 111CE21F95F4 for ; Fri, 19 Apr 2013 08:22:38 -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 eTO1tmLBlGRJ for ; Fri, 19 Apr 2013 08:22:37 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 324AF21F95F1 for ; Fri, 19 Apr 2013 08:22:11 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUXFhIqk7A3vG679HFAmi6CWZEEB+JlJn@postini.com; Fri, 19 Apr 2013 08:22:25 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r3JFM59u025688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 11:22:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 19 Apr 2013 11:22:04 -0400 From: "Dickson, Brian" To: Joe Abley , Masataka Ohta Thread-Topic: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... Thread-Index: AQHOPRGkEumdXjYvcU2s5W2pE+h9yw== Date: Fri, 19 Apr 2013 15:22:03 +0000 Message-ID: In-Reply-To: <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <32052ACFF4329841A9F39BF679C26760@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 19 Apr 2013 15:22:38 -0000 On 4/19/13 10:04 AM, "Joe Abley" wrote: >Ohta-san, > >On 2013-04-19, at 03:01, Masataka Ohta >wrote: > >>=20 >> But, the proposal not using just an EUI type (depends on RDLENGTH), >> but EUI48 and EUI64 types is inefficient w.r.t. RR type space >> and the number of queries to get EUI information of a node. > >In effect, to implement your suggestion would require a third code-point. Which would lead to: http://xkcd.com/927/ :-) Brian From sm@resistor.net Fri Apr 19 15:05:59 2013 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 9AC8121F8FED for ; Fri, 19 Apr 2013 15:05:59 -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 h79Pt3XIu9TT for ; Fri, 19 Apr 2013 15:05:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB921F8FD6 for ; Fri, 19 Apr 2013 15:05:58 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3JM5o1E022002; Fri, 19 Apr 2013 15:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366409155; bh=cwsRUnl9dGOF7s2wphE/u0WJR8bPoM1b0YopudVRzmo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L9sANX7RZuuT91jURkNGtl39jhMc2+P1DlGwjNdB2ojjS0+XbR6PfAOQYHQmAvCTv +aw0RiRhYSc5W9vaKf/wKqLZvyKd9ODanPkSTAhdvmkPHmCFICYGJ58zmV1yR5R/EL 0TmTbDp7HQOd5E0ot44mVKijCOu55Us8pGDexamc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366409155; i=@resistor.net; bh=cwsRUnl9dGOF7s2wphE/u0WJR8bPoM1b0YopudVRzmo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=b+EWCn+ByNstMBD1gxZ+ImBTyHorNqsQODGNL1iQCOlqNHjFII0yZoo59FAMk07q3 o4eHPh5qVqRAIPhxBDLvv0/Lu2d9UEOOy+WeV0EXhRQPST9THQVZCb1gLJWe9SiDo/ pBGD0ZGSoyuPi3b+rfKRK0oivrOb4trSfRM9Ogbw= Message-Id: <6.2.5.6.2.20130419141809.0cb2b9a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 19 Apr 2013 14:36:06 -0700 To: Donald Eastlake From: SM In-Reply-To: References: <516C346C.5050507@dougbarton.us> <6.2.5.6.2.20130417105851.0ca704f8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 19 Apr 2013 22:05:59 -0000 Hi Donald, At 12:05 17-04-2013, Donald Eastlake wrote: >I suppose it depends on what you mean by "special" but I believe that >informational RFCs issued by the IAB constitute at least a mild form >of architectural guidance. To quote from the abstract of 5507: "... >This document lists different mechanisms to extend the DNS, and >concludes that the use of a new DNS Resource Record Type is the best >solution." I sometimes read some of the (informational) RFCs issued by the IAB as guidance. I won't tell anyone that the RFC is more important than another RFC (what I meant by "special"). It helps (me) to have some mild form of architectural guidance as a way to avoid solving issues which have already been solved previously. Regards, -sm From mohta@necom830.hpcl.titech.ac.jp Mon Apr 22 01:15:27 2013 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 AB1F921F8DB9 for ; Mon, 22 Apr 2013 01:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.21 X-Spam-Level: * X-Spam-Status: No, score=1.21 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 0V0+2LtYQP5V for ; Mon, 22 Apr 2013 01:15:27 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 8FB3421F8D92 for ; Mon, 22 Apr 2013 01:15:26 -0700 (PDT) Received: (qmail 68927 invoked from network); 22 Apr 2013 08:13:03 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 Apr 2013 08:13:03 -0000 Message-ID: <5174F165.2080902@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Apr 2013 17:14:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joe Abley References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> In-Reply-To: <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 08:15:27 -0000 (2013/04/19 23:04), Joe Abley wrote: > It sounds like your counter-proposal would have been to specify > a single RRType with an additional field in the RDATA to > distinguish between EUI48 and EUI64, e.g. without drawing > the bitfields, something that might have a presentation format like > > owner1.example. 86400 IN EUI 48 7c-d1-c3-e8-10-2f > > I think that's a perfectly valid idea. However, two code points > have already been assigned for each of EUI48 and EUI64 at > this point, Worse, as: >> and the number of queries to get EUI information of a node. is still a problem, the third code point must be allocated. But, it is not my mistake. > and at least one vendor has implemented them according to the > currently-circulating specification. That were a valid argument if "some vendor has implemented it with TXT" were a valid argument against EUI48 and EUI64. > I think we can consider both assigned code points to be > polluted at this point, and hence revising the spec to > make use of a single RRType would (a) not actually > preserve a code point in the RRTypes registry, and (b) > would present interop problems against current > implementations if one of the assigned code-points was > re-used. In effect, to implement your suggestion would > require a third code-point. Yes, of course. If you insist on the current draft, I can write a draft and request the third code point, can't I? Masataka Ohta From jabley@hopcount.ca Mon Apr 22 03:40:41 2013 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 6F22C21F8E9E for ; Mon, 22 Apr 2013 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 1H95m5CTdBKS for ; Mon, 22 Apr 2013 03:40:40 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4444721F8E9A for ; Mon, 22 Apr 2013 03:40:40 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id hg5so298136qab.7 for ; Mon, 22 Apr 2013 03:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=zN7K/9P9LmNzaRskMPgbphmuqoqWRWggHmBVR2bEXaI=; b=IGTdrRv/4JJyuOua8xvgmzg201jQEi0ClqqjITJ74YKdOFwhc6/ECr1KFHI1z9GHWo j7P5k6n3EWU6g4AQxTMpA1c2gGiVnqZEfC3ivSqT2RhbkFd0JjaBtZPxz/IobnD3erR8 ymVMeYaQgEKTSo58MdYHWbg/AngQyWQXnPHrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zN7K/9P9LmNzaRskMPgbphmuqoqWRWggHmBVR2bEXaI=; b=Ygf1nxDgSPeVOGJNKRLK1dL4n02l2+1pTyzT9+v3Z3uM8kYGuJ92YpiVZEZsYYfpeX dfvH7WatAC5hUWownorIaMt0brwsrgQgaUhnSTdBIDAFelFtRpnPl5krmd+onziy4J/a cELDnsr11W3e/G2lVkDZqSzj2ek0L7NkRQrq1F2qqLH5eUkDHx/CqcX3sQymb/lQNrRg 5i6ST7YSYYwN/+it3ByAYIgBPhyiMlxcgWCHGiZdyWL/+AQF0ODuS/soX60eO2aKF/uT aAz/cII7Gcguh1zjQobtz0wv3iQowK0ahvU8Nng5dxQc0RNNrgZeuZvXQiifGxmde+Tc 0R3Q== X-Received: by 10.224.11.200 with SMTP id u8mr21909527qau.76.1366627231783; Mon, 22 Apr 2013 03:40:31 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id z2sm27824354qad.4.2013.04.22.03.40.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 03:40:31 -0700 (PDT) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <5174F165.2080902@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Apr 2013 06:40:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmvOre3TE0hjMd5vGN92F6EBaHbzh3JIV8iWpdtrAJpr4qa+hApMldtmUlvGoiC5MdJQFt7 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 10:40:41 -0000 On 2013-04-22, at 04:14, Masataka Ohta = wrote: > If you insist on the current draft, I can write a draft and > request the third code point, can't I? Yes, of course. Since there are already code-points assigned for the = publication of EUI48/EUI64 addresses in the DNS now, though, it seems = possible that such a request would be denied though, on that basis. Joe= From dougb@dougbarton.us Mon Apr 22 11:02:11 2013 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 B5F4021F93FC for ; Mon, 22 Apr 2013 11:02:11 -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 TArNxBAULJ7x for ; Mon, 22 Apr 2013 11:02:11 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1371B21F93F9 for ; Mon, 22 Apr 2013 11:02:11 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b845:5732:27d2:c1bc] (unknown [IPv6:2001:470:d:5e7:b845:5732:27d2:c1bc]) by dougbarton.us (Postfix) with ESMTPSA id 249D622C1D for ; Mon, 22 Apr 2013 18:02:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366653725; bh=0bzGFWS7WSY2BJBbXrutKautToAPLEgLEUC1s5KwtAk=; h=Date:From:To:Subject:References:In-Reply-To; b=GNx7jBtaqxPGn0Uwm4IsdwkraA74BvVBHlLJ8Oe9E33BHz1Vj62thxndqL1hdN2iP Hjto5Kmtt47L89CEbskhCNwr6JUkTvDnmtVWQwyxLmAwHvXLq6/R/fP9dzF8pU0Ubg phZE73rifnlPgYerg/AfRMN8tcBxQtCIPwtVef34= Message-ID: <51757B1C.2020708@dougbarton.us> Date: Mon, 22 Apr 2013 11:02:04 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> In-Reply-To: <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 18:02:11 -0000 On 04/22/2013 03:40 AM, Joe Abley wrote: > > On 2013-04-22, at 04:14, Masataka Ohta wrote: > >> If you insist on the current draft, I can write a draft and >> request the third code point, can't I? > > Yes, of course. Since there are already code-points assigned for the publication of EUI48/EUI64 addresses in the DNS now, though, it seems possible that such a request would be denied though, on that basis. Um, wait. I thought code points should be free, and easy to obtain. What's the harm in having a different way to represent similar data? If down the road someone comes up with a fourth option that is clearly vastly superior to either of your proposals, should they also be denied? Doug From jabley@hopcount.ca Mon Apr 22 11:23:04 2013 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 A2BB621E8044 for ; Mon, 22 Apr 2013 11:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 4kM5fLs9Zw7J for ; Mon, 22 Apr 2013 11:23:03 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2FA21F8F4F for ; Mon, 22 Apr 2013 11:23:02 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so1516182qca.23 for ; Mon, 22 Apr 2013 11:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=LvImB/gFHZzcboYuwJ5EQNX8IOLaMj5lEj84fitHFS4=; b=dIzOxxnWB0lNqPq5i6Ah+52iqOEQYVJ2uHOTuUGUDqiad7q70w9dpGytVE5q8GoVh+ TMNZy6mga6uDcTsvZTZGVcGuw7Pp7JsP4hzo1KQEq1XYmfQm5YQjBrXa93WxCY+RlBFe 4HrfNB1WkiJRxFyM2PcZ6CYT3NX6U+odIKpJ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LvImB/gFHZzcboYuwJ5EQNX8IOLaMj5lEj84fitHFS4=; b=Z9uNZG25ay1qNPTyLhsxscLkDqp4zwF31SxNryIzbtpPO7ERYSwvxjJFbpTtIw3EIh 1U74Arqx/uwYhRFpw/hUJDdXoMuadzW+AOI7jRQJjj1qyFy21Us0bNaCx3bVR2ezgOat SSgqbR0pJADOxLznPNNGw5WB3nq0IdaX4QT+UlRRibNubESP5D7VkrdIKvyIExrLpSEl Dfz928+B1e99Ltnvvf4CjOTY7q5Vm2srcbzivoN8J+2NVOzh8jIGJ3ZK6ImhnsTsXmDL 7FXaKLQgo4IrkOF+w4Hpn1Z10cWUTZ08WbDu8mpAiMT+EBHj8ZqPimqwIzhgAFf1MepL z1Zw== X-Received: by 10.229.129.19 with SMTP id m19mr5506845qcs.19.1366654981644; Mon, 22 Apr 2013 11:23:01 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id n3sm2846175qat.6.2013.04.22.11.22.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 11:22:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <51757B1C.2020708@dougbarton.us> Date: Mon, 22 Apr 2013 14:22:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B4B3F9D-761E-4E10-AADF-D81071B731AB@hopcount.ca> References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkGp8lZhAXE/IvyBk6qRgFskJQDC1V3D64gc7Aw95Lk+VZTC0hxX3x9+FjRP/84QTaoeVW0 Cc: dnsext@ietf.org Subject: [dnsext] Doug's eager anticipation of RFC6895bis (was Re: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...) 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, 22 Apr 2013 18:23:04 -0000 On 2013-04-22, at 14:02, Doug Barton wrote: > On 04/22/2013 03:40 AM, Joe Abley wrote: >>=20 >> On 2013-04-22, at 04:14, Masataka Ohta = wrote: >>=20 >>> If you insist on the current draft, I can write a draft and >>> request the third code point, can't I? >>=20 >> Yes, of course. Since there are already code-points assigned for the = publication of EUI48/EUI64 addresses in the DNS now, though, it seems = possible that such a request would be denied though, on that basis. >=20 > Um, wait. I thought code points should be free, and easy to obtain. = What's the harm in having a different way to represent similar data? If = down the road someone comes up with a fourth option that is clearly = vastly superior to either of your proposals, should they also be denied? I guess that's down to the expert review. I thought there was some = explicit text in 6195 or 6895 that touched on this, but in fact what I = was remembering was question F in the allocation template (e.g. see 6895 = appendix A). F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? Quite possibly I was reading more into that question than was intended. Joe= From ajs@anvilwalrusden.com Mon Apr 22 11:28:58 2013 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 0589921F933F for ; Mon, 22 Apr 2013 11:28:58 -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 ikd0fBJmchgQ for ; Mon, 22 Apr 2013 11:28:57 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85B21F933B for ; Mon, 22 Apr 2013 11:28:57 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C2A2A8A031 for ; Mon, 22 Apr 2013 18:28:56 +0000 (UTC) Date: Mon, 22 Apr 2013 14:28:55 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130422182854.GO15031@mx1.yitter.info> References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51757B1C.2020708@dougbarton.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] typecode allocation policy (was: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...) 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, 22 Apr 2013 18:28:58 -0000 No hat. On Mon, Apr 22, 2013 at 11:02:04AM -0700, Doug Barton wrote: > What's the harm in having a different way to represent similar data? Nobody needs to show harm here, because the guidance to experts in RFC 6895 (found in section 3.1.2, specifically number 4) says the expert shouldn't approve requests "when the purpose could be met with a smaller number of values or with Private Use values." If there are people who would like the procedures for RRTYPE assignment to change, I encourage them to submit draft-doe-wannabe-dns-cops-00 or whatever it should be called. But it seems to me that arguing about the goodness of the allocation procedure that is actually in operation is not a great use of participants' time. Note that the WG is not taking up any more documents, so a new IANA procedure for DNS RRTYPE code assignment would have to go through another route. Perhaps an AD sponsorship. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dougb@dougbarton.us Mon Apr 22 12:02:00 2013 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 927E121E80A6 for ; Mon, 22 Apr 2013 12:02:00 -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 iZbIzd-cfyqO for ; Mon, 22 Apr 2013 12:02:00 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C548021E80B0 for ; Mon, 22 Apr 2013 12:01:58 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9] (unknown [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9]) by dougbarton.us (Postfix) with ESMTPSA id 0DA5322C25 for ; Mon, 22 Apr 2013 19:01:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366657318; bh=vALsCqcgqin3C1ZIkBJx7VWHVzSPPTWwk7quuvoGpHM=; h=Date:From:To:Subject:References:In-Reply-To; b=MSSVC2WLR6oClh+s5YjoQOnyDKmu+yEjSato+rdibjom055EeCYu2bZfcT6A3b/aa gMiG+gIJc99Hd+gQexQxQSSZ6l0bCuMBnHOXCYWxAa8zV0RV5VY+U6ht3EfPUlQpS0 CqHGcMz3P9IjNDu5R1GLEhusbZ2rgJXSEOkdf+1Q= Message-ID: <51758925.2020007@dougbarton.us> Date: Mon, 22 Apr 2013 12:01:57 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> <20130422182854.GO15031@mx1.yitter.info> In-Reply-To: <20130422182854.GO15031@mx1.yitter.info> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] typecode allocation policy 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, 22 Apr 2013 19:02:00 -0000 On 04/22/2013 11:28 AM, Andrew Sullivan wrote: > No hat. > > On Mon, Apr 22, 2013 at 11:02:04AM -0700, Doug Barton wrote: > >> What's the harm in having a different way to represent similar data? > > Nobody needs to show harm here, because the guidance to experts in RFC > 6895 (found in section 3.1.2, specifically number 4) says the expert > shouldn't approve requests "when the purpose could be met with a > smaller number of values or with Private Use values." Sure, so my theoretical case would be approved (assuming the new type actually is superior). > If there are people who would like the procedures for RRTYPE > assignment to change Not my purpose at all ... clearly my previous understanding was incorrect, and I was met with "it should be easy to allocate a new type." Now someone else is proposing a new type, and the same folks are saying "no, you shouldn't get your new type." I'm confused. Doug From d3e3e3@gmail.com Mon Apr 22 12:32:14 2013 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 E319521E809D for ; Mon, 22 Apr 2013 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 iCej+D9ZXxKd for ; Mon, 22 Apr 2013 12:32:14 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 005DE21E8097 for ; Mon, 22 Apr 2013 12:32:13 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so4586587oah.35 for ; Mon, 22 Apr 2013 12:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=SjaUsfSlKX8YGHvYdls/ECJ/cjahC/oZr+t4Y8PysRI=; b=Vh67Wh8Hbp/hcycc7hRtlNOG7+rVUb/lXzZmXeGc3tmcX3rvB7m+r/C/rqTHvPhZjT /uYKQIM9R6svgUEfYO9aiWo6FsG/4w7z5SMA+f7ijUxno2kLL+1+DPPZSk0V15P1K8hf kpFZPgym6EFF2BPSme+S5n5FIMY4kfkKG316mMrkqwTifOkR1+cuUIg37aEdl0MvkAmF LkT21vc/0bAYaTZJs9WTKwUpUPRaKsZDI+swTvxU24lAsb1jl4LDSZ9D1RdwjeZmKmn1 Z4sN1ADAtehkaDGbG2xKZOaxHtZnyqhbz3M5dV6ku554QS8OV/qNjylUkLcmZ+l3k7rB U9dg== X-Received: by 10.60.94.72 with SMTP id da8mr11299678oeb.15.1366659133444; Mon, 22 Apr 2013 12:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Mon, 22 Apr 2013 12:31:53 -0700 (PDT) In-Reply-To: <20130415221143.2E57721F93F3@ietfa.amsl.com> References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <20130415221143.2E57721F93F3@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 22 Apr 2013 15:31:53 -0400 Message-ID: To: Joe Abley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dnsext@ietf.org Group" , dnsops@ietf.org, draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 19:32:15 -0000 I'm not against all additions of text to this draft. Here is my suggested text, partly based on Michael StJohn's suggestions: Possible main body text: The specification of the new RRTYPEs in this document has no effect on the address resolution behavior of any previously existing network processes or protocols. Proposals or specifications to modify or augment address resolution processes or protocols by making use of these RRTPES should specify how any address conflicts or multiple EUI RR occurrences or the like are handled. Possible Security Considerations text: There may be privacy concerns with publishing EUI RRs in the global DNS. EUI addresses with the Global bit zero [RFC5342] are supposed to represent unique identifiers for network connected equipment notwithstanding many observed cases of duplication due to manufacturing errors, unauthorized use of OUIs, and address spoofing through configuration of network interfaces. Inclusion of EUI RRs in the global DNS may result in privacy issues in the form of unique trackable identities. IP addresses and DNS names for network devices typically change over time but EUIs normally provide a unique identity for a network device. As an example of this, consider a wireless provider that publishes EUI information for its subscribers in the global DNS under the same name as their IP host name. An entity that wants to relate web queries, for example, to a specific customer might, if that customer is using a globally routable IP address, be able to do a reverse query from the IP address to a DNS name, and then a forward query for the EUI information. If possible, this would enable a tracking entity to relate queries to specific identity regardless of changes in IP addresses and DNS names resulting in a loss of privacy for the subscriber. These potential concerns can be mitigated through restricting access to zones containing EUI RRs and/or storage of such information under a domain name whose construction requires that the querier already know some other permanent identifier. 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 On Mon, Apr 15, 2013 at 6:11 PM, Michael StJohns wro= te: > At 07:53 AM 4/15/2013, Joe Abley wrote: > >>On 2013-04-15, at 02:53, list reader DNSEXT wrote: >> >>> I think there's an error in section 4.1 where it should say EUI64 but >>> actually says EUI48. >> >>I think you're right. Thanks for that! I will make changes. >> >>> and +1 for the privacy concerned >> >>Can you explain further? I don't understand those concerns. > > > Suggested paragraphs for the security section. > > [ PRIVACY: > There may be privacy concerns with publishing EUI RRs. EUI64 and EUI48 r= epresent unique identifiers for network connected equipment. As such, thei= r inclusion within the DNS may result in privacy issues in the form of uniq= ue trackable identities. Unlike the IP addresses and DNS names for network= devices which can and do change over time, the EUI information will almost= always uniquely identify a device (or more specifically, a network interfa= ce). As an example of this, consider a wireless provider that publishes EU= I information for its subscribers. An entity that wants to relate web quer= ies, for example, to a specific customer need only do a reverse query from = the IP address to a DNS name, and then a forward query for the EUI informat= ion. The tracking entity may relate all queries to specific unique identit= ies regardless of changes in IP addresses and DNS names resulting in a poss= ible loss of privacy for the subscriber. > > Transitive Trust: > > DNSSEC allows the binding of a name to one or more RR's. It is possible = to use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same = name. This should probably not be consider as a secure binding between an = IP address and an EUI64/48 address. {Not sure where this should go - this = gets perilously close to secure ARP and placing this in the hands of the do= main owner rather than the hands of the network owner is probably a "bad th= ing" } > > > Paragraph for the main body: > > [ > EUI64 and EUI48 addresses represent another way of referencing a network = connected host past IP addresses and DNS names. Any system which deploys E= UI64 and EUI48 RR's should consider how to maintain consistency between the= various systems which may be involved in such mapping. Specifically, DNS,= DHCP, and ARP. Any application that desires to make use of EUI64 and EUI= 48 RR's for any other use beyond simple data storage should consider how to= resolve at least the following possible inconsistencies in data in the DNS= and local network information: > > 1) A mismatch for the same name where the device referenced by the A and= AAAA records do not represent the same device as those referenced by the E= UI64 and EUI48 RRs. (E.g. the ARP response for a local IP address does not= yield one of the values in an EUI64 or EUI48 RR). > > 2) A query for a specific name which returns multiple EUI64 and EUI48 rec= ords. > > 3) A query for a specific name which returns only EUI64 and EUI48 records= and does not return either of A or AAAA records. > > > > > >>This document provides a specification for a structured way of storing pa= rticular data in the DNS. It's not data that can't be stored today using mo= re general RRTypes like TXT. It doesn't advocate publication of anything. W= hat are the privacy concerns? >> >>If there are concerns that people should take time to understand the priv= acy implications of publishing subscriber data in the DNS, then that seems = entirely valid. But this is not a draft about publishing subscriber data in= the DNS, it's a draft about implementing specific RRTypes. >> >>If there is useful information for the IETF to publish about privacy cons= iderations in the DNS, I don't understand why that should be specific to th= ese particular RRTypes. Are similar privacy concerns not also applicable to= the DNS in general? >> >>I've seen people distribute password hashes and user identities in the DN= S before, as a back-end to tacacs servers deployed to authenticate dial-up = users. (OK, this is going back a bit.) Surely if there is advice to be give= n about the publication of subscriber data in the DNS we would want to talk= about the general approach, and not specific RRTypes. >> >>Would we caution people about storing MAC addresses in an EUI48 RR, but n= ot bother to caution other people about storing the same data in TXT record= s? >> >>etc, etc. >> >> >>Joe From d3e3e3@gmail.com Mon Apr 22 12:39:05 2013 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 25D7F21F8FF2 for ; Mon, 22 Apr 2013 12:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 u5fNmKf7Yo3t for ; Mon, 22 Apr 2013 12:39:04 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3021F8FE8 for ; Mon, 22 Apr 2013 12:39:04 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id dn14so5790173obc.27 for ; Mon, 22 Apr 2013 12:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=NZe0pKcvfLYldObMmP12pkhtH7D77XENWpr3IRmrQic=; b=AngwnkYb7sbStSSJ+7RnCcjyTjuMCqLiexROTCpt2s9S1GAyaCVWbQsdYtIiqrgJJb qXuj+eZ4/bKQCVl5aSZERLKgU80ad64RbzuW+aSfh4cWlKefqc8oRCCzx4FLRkq+Tp2m OfCweJxsHifgzGHFntiElT3AbMsBMle1Ahk/ADaGBVjGSnaRl3BOyl+XrEMP+DWTSBvh drkeie7HEJbvWm+p1RiLOb7J5eWRP6g+Xl/q7R/U2R8Dt/HPKKdpRGqjWUQbijjBekTp 79YRxRz+qyQNhUOZnfHdEmOTaLvGsN7KZMdxDXo6hhQE6aiDkIpyjr3ulwhlGJ4asTSf kVFA== X-Received: by 10.60.23.70 with SMTP id k6mr16014271oef.90.1366659544221; Mon, 22 Apr 2013 12:39:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Mon, 22 Apr 2013 12:38:44 -0700 (PDT) In-Reply-To: <51757B1C.2020708@dougbarton.us> References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> From: Donald Eastlake Date: Mon, 22 Apr 2013 15:38:44 -0400 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 19:39:05 -0000 On Mon, Apr 22, 2013 at 2:02 PM, Doug Barton wrote: > On 04/22/2013 03:40 AM, Joe Abley wrote: >> >> >> On 2013-04-22, at 04:14, Masataka Ohta >> wrote: >> >>> If you insist on the current draft, I can write a draft and >>> request the third code point, can't I? >> >> Yes, of course. Since there are already code-points assigned for the >> publication of EUI48/EUI64 addresses in the DNS now, though, it seems >> possible that such a request would be denied though, on that basis. > > Um, wait. I thought code points should be free, and easy to obtain. What's > the harm in having a different way to represent similar data? If down the > road someone comes up with a fourth option that is clearly vastly superior > to either of your proposals, should they also be denied? The policy is not first come, first served. It is lenient, not free. It is an Expert judgement call. Having multiple ways of representing the same data doesn't hurt much if they are used for different purposes. If they are used for the same purpose and some might be using one and some the other, it multiplies the number of queries since you should check for all of them. But of course, if there is a *vastly superior* way, then one could hope that everyone would eventually switch to the new way. So in that case it might make sense to have a new way to represent the same data for the same purpose and accept a transient increase in queries. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Doug From mstjohns@comcast.net Mon Apr 22 12:40:54 2013 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 406AD21F9132 for ; Mon, 22 Apr 2013 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.739 X-Spam-Level: X-Spam-Status: No, score=-99.739 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 N7qfWx4wBQuM for ; Mon, 22 Apr 2013 12:40:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB721E80B6 for ; Mon, 22 Apr 2013 12:40:53 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id Syhj1l0021ap0As537gpfv; Mon, 22 Apr 2013 19:40:49 +0000 Received: from [192.168.1.102] ([68.83.212.126]) by omta22.westchester.pa.mail.comcast.net with comcast id T7gn1l01w2kB7pQ3i7goXB; Mon, 22 Apr 2013 19:40:49 +0000 References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516b4ac9.8308dd0a.2c46.ffffd5bfSMTPIN_ADDED_MISSING@mx.google.com> <0418525B-9E68-4918-9A20-70507DF5C12A@hopcount.ca> <1366008833.28765.140661217831926.5C7F65A2@webmail.messagingengine.com> <20130415221143.2E57721F93F3@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <11C3DD7D-C709-473B-8537-4EF30C4FCFC7@comcast.net> X-Mailer: iPad Mail (10A550) From: Michael StJohns Date: Mon, 22 Apr 2013 15:40:52 -0400 To: Donald Eastlake DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366659649; bh=Q9BlHJ3rwthMGW0DAh5z3TXTi8oHmSzvxc4m08sbW8I=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=cXlRNnwZRGjQrntLTOvfDu4ZYDacOHwUnWf7LW0+Yg/w6be8JDBGe8nkeDcbzKflY 3vyTC5JXtZ8WI8hQtQByJdvOpxXwQ6h/qRSmhOsLbrI+HaFjznWDhsbN1XA57c+Rw3 JnwhvKxYzZk1xH01E98u0LZtqphmiFAobFRncuk5Qo6LdkHMJrd+0vDC7UiXunsztW MfNGGNeF8XBtJxiz/p4KBfGkQcM4pGLFJzjAlLJSjMlSX+nNb9+I3Gd6CjZB0/Sayf eP5bx/ELgFbRnYIT2be9PJaroxuCKFxKMU0lo80v6G6+hTgunplNj2dPwaqdVmUNAZ EK4cZfrbdqShw== Cc: "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" , "dnsops@ietf.org" , "dnsext@ietf.org Group" Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 19:40:54 -0000 Works for me. Thanks - Mike Sent from my iPad On Apr 22, 2013, at 15:31, Donald Eastlake wrote: > I'm not against all additions of text to this draft. Here is my > suggested text, partly based on Michael StJohn's suggestions: >=20 >=20 > Possible main body text: >=20 > The specification of the new RRTYPEs in this document has no effect on > the address resolution behavior of any previously existing network > processes or protocols. Proposals or specifications to modify or > augment address resolution processes or protocols by making use of > these RRTPES should specify how any address conflicts or multiple EUI > RR occurrences or the like are handled. >=20 >=20 > Possible Security Considerations text: >=20 > There may be privacy concerns with publishing EUI RRs in the global > DNS. EUI addresses with the Global bit zero [RFC5342] are supposed to > represent unique identifiers for network connected equipment > notwithstanding many observed cases of duplication due to > manufacturing errors, unauthorized use of OUIs, and address spoofing > through configuration of network interfaces. Inclusion of EUI RRs in > the global DNS may result in privacy issues in the form of unique > trackable identities. IP addresses and DNS names for network devices > typically change over time but EUIs normally provide a unique identity > for a network device. As an example of this, consider a wireless > provider that publishes EUI information for its subscribers in the > global DNS under the same name as their IP host name. An entity that > wants to relate web queries, for example, to a specific customer > might, if that customer is using a globally routable IP address, be > able to do a reverse query from the IP address to a DNS name, and then > a forward query for the EUI information. If possible, this would > enable a tracking entity to relate queries to specific identity > regardless of changes in IP addresses and DNS names resulting in a > loss of privacy for the subscriber. These potential concerns can be > mitigated through restricting access to zones containing EUI RRs > and/or storage of such information under a domain name whose > construction requires that the querier already know some other > permanent identifier. >=20 >=20 > 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 >=20 >=20 > On Mon, Apr 15, 2013 at 6:11 PM, Michael StJohns wr= ote: >> At 07:53 AM 4/15/2013, Joe Abley wrote: >>=20 >>> On 2013-04-15, at 02:53, list reader DNSEXT wrote= : >>>=20 >>>> I think there's an error in section 4.1 where it should say EUI64 but >>>> actually says EUI48. >>>=20 >>> I think you're right. Thanks for that! I will make changes. >>>=20 >>>> and +1 for the privacy concerned >>>=20 >>> Can you explain further? I don't understand those concerns. >>=20 >>=20 >> Suggested paragraphs for the security section. >>=20 >> [ PRIVACY: >> There may be privacy concerns with publishing EUI RRs. EUI64 and EUI48 r= epresent unique identifiers for network connected equipment. As such, their= inclusion within the DNS may result in privacy issues in the form of unique= trackable identities. Unlike the IP addresses and DNS names for network de= vices which can and do change over time, the EUI information will almost alw= ays uniquely identify a device (or more specifically, a network interface). = As an example of this, consider a wireless provider that publishes EUI info= rmation for its subscribers. An entity that wants to relate web queries, fo= r example, to a specific customer need only do a reverse query from the IP a= ddress to a DNS name, and then a forward query for the EUI information. The= tracking entity may relate all queries to specific unique identities regard= less of changes in IP addresses and DNS names resulting in a possible loss o= f privacy for the subscriber. >>=20 >> Transitive Trust: >>=20 >> DNSSEC allows the binding of a name to one or more RR's. It is possible t= o use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same na= me. This should probably not be consider as a secure binding between an IP a= ddress and an EUI64/48 address. {Not sure where this should go - this gets p= erilously close to secure ARP and placing this in the hands of the domain ow= ner rather than the hands of the network owner is probably a "bad thing" } >>=20 >>=20 >> Paragraph for the main body: >>=20 >> [ >> EUI64 and EUI48 addresses represent another way of referencing a network c= onnected host past IP addresses and DNS names. Any system which deploys EUI= 64 and EUI48 RR's should consider how to maintain consistency between the va= rious systems which may be involved in such mapping. Specifically, DNS, DHC= P, and ARP. Any application that desires to make use of EUI64 and EUI48 RR= 's for any other use beyond simple data storage should consider how to resol= ve at least the following possible inconsistencies in data in the DNS and lo= cal network information: >>=20 >> 1) A mismatch for the same name where the device referenced by the A and= AAAA records do not represent the same device as those referenced by the EU= I64 and EUI48 RRs. (E.g. the ARP response for a local IP address does not y= ield one of the values in an EUI64 or EUI48 RR). >>=20 >> 2) A query for a specific name which returns multiple EUI64 and EUI48 rec= ords. >>=20 >> 3) A query for a specific name which returns only EUI64 and EUI48 records= and does not return either of A or AAAA records. >>=20 >>=20 >>=20 >>=20 >>=20 >>> This document provides a specification for a structured way of storing p= articular data in the DNS. It's not data that can't be stored today using mo= re general RRTypes like TXT. It doesn't advocate publication of anything. Wh= at are the privacy concerns? >>>=20 >>> If there are concerns that people should take time to understand the pri= vacy implications of publishing subscriber data in the DNS, then that seems e= ntirely valid. But this is not a draft about publishing subscriber data in t= he DNS, it's a draft about implementing specific RRTypes. >>>=20 >>> If there is useful information for the IETF to publish about privacy con= siderations in the DNS, I don't understand why that should be specific to th= ese particular RRTypes. Are similar privacy concerns not also applicable to t= he DNS in general? >>>=20 >>> I've seen people distribute password hashes and user identities in the D= NS before, as a back-end to tacacs servers deployed to authenticate dial-up u= sers. (OK, this is going back a bit.) Surely if there is advice to be given a= bout the publication of subscriber data in the DNS we would want to talk abo= ut the general approach, and not specific RRTypes. >>>=20 >>> Would we caution people about storing MAC addresses in an EUI48 RR, but n= ot bother to caution other people about storing the same data in TXT records= ? >>>=20 >>> etc, etc. >>>=20 >>>=20 >>> Joe > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From dougb@dougbarton.us Mon Apr 22 12:52:20 2013 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 200F821F936F for ; Mon, 22 Apr 2013 12:52:20 -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 sZ83GXK6cb88 for ; Mon, 22 Apr 2013 12:52:19 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5089321F936C for ; Mon, 22 Apr 2013 12:52:19 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9] (unknown [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9]) by dougbarton.us (Postfix) with ESMTPSA id C65B422C25 for ; Mon, 22 Apr 2013 19:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366660336; bh=5G63Qrdyfo5eFdO5OjWksAvivZihtupxUnJHlgLJRFA=; h=Date:From:To:Subject:References:In-Reply-To; b=TYH7Wdd0li7IetB6uOVu2EQ6FzNAKldXTpcG8k7WqXHqqt9KiP/Hp88QTk7fh90QF wpCA55uyitktSgmuFGaOplxYaaGCBlTs9sXTxK8dlRSo5TV9FkBIUGc/yoI7Q2xYL5 XwM0yKgnAvZy9ngN6xPtYeg6b4SDSCpNlosWtCAM= Message-ID: <517594F0.8050105@dougbarton.us> Date: Mon, 22 Apr 2013 12:52:16 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 19:52:20 -0000 On 04/22/2013 12:38 PM, Donald Eastlake wrote: > On Mon, Apr 22, 2013 at 2:02 PM, Doug Barton wrote: >> On 04/22/2013 03:40 AM, Joe Abley wrote: >>> >>> >>> On 2013-04-22, at 04:14, Masataka Ohta >>> wrote: >>> >>>> If you insist on the current draft, I can write a draft and >>>> request the third code point, can't I? >>> >>> Yes, of course. Since there are already code-points assigned for the >>> publication of EUI48/EUI64 addresses in the DNS now, though, it seems >>> possible that such a request would be denied though, on that basis. >> >> Um, wait. I thought code points should be free, and easy to obtain. What's >> the harm in having a different way to represent similar data? If down the >> road someone comes up with a fourth option that is clearly vastly superior >> to either of your proposals, should they also be denied? > > The policy is not first come, first served. It is lenient, not free. > It is an Expert judgement call. > > Having multiple ways of representing the same data doesn't hurt much > if they are used for different purposes. If they are used for the same > purpose and some might be using one and some the other, it multiplies > the number of queries since you should check for all of them. Sure, I agree with that of course. I also had in mind the "same data, but different (or dissimilar) purposes." > But of course, if there is a *vastly superior* way, then one could > hope that everyone would eventually switch to the new way. So in that > case it might make sense to have a new way to represent the same data > for the same purpose and accept a transient increase in queries. Your explanation makes sense, thanks for helping me understand. Doug From mohta@necom830.hpcl.titech.ac.jp Mon Apr 22 16:24:46 2013 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 26F301F0D29 for ; Mon, 22 Apr 2013 16:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 uVZJfWD8K7rH for ; Mon, 22 Apr 2013 16:24:44 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 78E381F0D20 for ; Mon, 22 Apr 2013 16:24:34 -0700 (PDT) Received: (qmail 83677 invoked from network); 22 Apr 2013 23:22:05 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 Apr 2013 23:22:05 -0000 Message-ID: <5175C685.9080307@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Apr 2013 08:23:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> In-Reply-To: <51757B1C.2020708@dougbarton.us> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 22 Apr 2013 23:24:46 -0000 Doug Barton wrote: >>> If you insist on the current draft, I can write a draft and >>> request the third code point, can't I? >> >> Yes, of course. Since there are already code-points assigned for the >> publication of EUI48/EUI64 addresses in the DNS now, though, it seems >> possible that such a request would be denied though, on that basis. > > Um, wait. I thought code points should be free, and easy to obtain. > What's the harm in having a different way to represent similar data? That is not a problem as my draft will obsolete clearly inefficient way with EUI48/EUI64 and EUI48/EUI64 specification is not published as an RFC yet. As I already wrote: > That were a valid argument if "some vendor has implemented it > with TXT" were a valid argument against EUI48 and EUI64. that there are informal ways to represent some data does not block to have a formal way to do so, even though someone has implemented the informal ways. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Mon Apr 22 16:33:15 2013 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 9ABFE21F937B for ; Mon, 22 Apr 2013 16:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 pmxIX6r8+3MU for ; Mon, 22 Apr 2013 16:33:15 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id ACA1F21F8512 for ; Mon, 22 Apr 2013 16:33:14 -0700 (PDT) Received: (qmail 83778 invoked from network); 22 Apr 2013 23:30:52 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 Apr 2013 23:30:52 -0000 Message-ID: <5175C894.9040204@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Apr 2013 08:32:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> <20130422182854.GO15031@mx1.yitter.info> In-Reply-To: <20130422182854.GO15031@mx1.yitter.info> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] typecode allocation policy 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, 22 Apr 2013 23:33:15 -0000 Andrew Sullivan wrote: > Nobody needs to show harm here, because the guidance to experts in RFC > 6895 (found in section 3.1.2, specifically number 4) says the expert > shouldn't approve requests "when the purpose could be met with a > smaller number of values or with Private Use values." Don't quote the RFC wrongly. The text in the RFC is: 4. An excessive number of RRTYPE values is being requested when the purpose could be met with a smaller number of values or with Private Use values. Do you mean 1 is an excessive number? If so, as 2 is clearly more excessive than 1, the original request with EUI48/EUI64 should have been denied as the purpose can be met with a smaller number of value. Masataka Ohta From ogud@ogud.com Mon Apr 22 18:35:56 2013 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 C0E4111E80E1 for ; Mon, 22 Apr 2013 18:35:56 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 IJRi9HdA6LBd for ; Mon, 22 Apr 2013 18:35:56 -0700 (PDT) Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com [108.166.43.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5166521F8E6A for ; Mon, 22 Apr 2013 18:35:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 503221B80C1; Mon, 22 Apr 2013 21:35:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1AB921B80B1; Mon, 22 Apr 2013 21:35:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: <5175C685.9080307@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Apr 2013 21:35:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5170EBDC.7000801@necom830.hpcl.titech.ac.jp> <7794F2EA-1512-425A-9EA4-C757B2478A3F@hopcount.ca> <5174F165.2080902@necom830.hpcl.titech.ac.jp> <4C874F4B-B7C6-4691-BC28-563441ED2A52@hopcount.ca> <51757B1C.2020708@dougbarton.us> <5175C685.9080307@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... 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, 23 Apr 2013 01:35:56 -0000 On Apr 22, 2013, at 7:23 PM, Masataka Ohta = wrote: > Doug Barton wrote: >=20 >>>> If you insist on the current draft, I can write a draft and >>>> request the third code point, can't I? >>>=20 >>> Yes, of course. Since there are already code-points assigned for the=20= >>> publication of EUI48/EUI64 addresses in the DNS now, though, it = seems=20 >>> possible that such a request would be denied though, on that basis. >>=20 >> Um, wait. I thought code points should be free, and easy to obtain.=20= >> What's the harm in having a different way to represent similar data? >=20 > That is not a problem as my draft will obsolete clearly inefficient > way with EUI48/EUI64 and EUI48/EUI64 specification is not published > as an RFC yet. >=20 =20 Ohta'san makes a good point, the currently allocated points are not in = use=20 thus they can be reassigned at later point i.e. after we all stop caring = about DNS.=20 Lets just live with the "wasted" code points. Olafur From jabley@hopcount.ca Tue Apr 23 05:46:10 2013 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 3E9E521F9663 for ; Tue, 23 Apr 2013 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ynXfHbmhLoFh for ; Tue, 23 Apr 2013 05:46:09 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1C121F965E for ; Tue, 23 Apr 2013 05:46:09 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id s35so321879dak.41 for ; Tue, 23 Apr 2013 05:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:from:content-type:content-transfer-encoding:subject:date :references:to:message-id:mime-version:x-mailer; bh=jwRa3rzgkj4P9rfqPNEo3DHW0hJ0k0o48/VtxgnbiwQ=; b=bPtkaVlN3/82tmATr2s35YGKbyEPLN3PFjl7IGa396NoGKn2mqPfKTW8CLMEuN7YnQ 9R5naqKu5C9B4R7QZpbzaxTI3hyRvAV/RcenaS6IL7vVz7291sG6VSlqiYXfhcaVi/3x L21m4z3GkpcFJgRTpVehfQ8jJ12UBIyUgewho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :references:to:message-id:mime-version:x-mailer:x-gm-message-state; bh=jwRa3rzgkj4P9rfqPNEo3DHW0hJ0k0o48/VtxgnbiwQ=; b=KHSHgq9sQrdG8Mi0am8wnw4MIGKZBNoxwMz3dyxrUoR/wy04gfO62KbpG+70cYE5UU WQ8/6PYO8cXbIa5D132+4nZU5O8irKgVrR7myDjoi6pHYXzYZAabSzLjrsFBRM1tqRRo ed1IX9o6VKDLskC1nClU42FZ7+iDLUfRkMe82Nj6KqiiagOIIHFBlxxCwBzxtvi0trXa KoOW6bx2XPtYeODmB8Q0AA/22K2ZYELb8TkVBocjLv20QWnk4xa9fHAiTfNcrXseA4He AISaDqgSPd8U7/3orWsb4aa4Ec9tUNZaIpBwHvuIMvTNGQTXQo+xT2R5m1rWyAzLXJVW 8pXA== X-Received: by 10.68.177.33 with SMTP id cn1mr6240669pbc.189.1366721168890; Tue, 23 Apr 2013 05:46:08 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:f555:6e68:4ae:fce? ([2001:4900:1042:100:f555:6e68:4ae:fce]) by mx.google.com with ESMTPS id l4sm23907068pbo.6.2013.04.23.05.46.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 05:46:07 -0700 (PDT) From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Apr 2013 08:46:03 -0400 References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> To: "dnsext@ietf.org Group" Message-Id: <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk90wmNzvjsrlRSeAd1WjwO0NmtKI0dzTo9PSQFjxOOHWaDRq8nW8F+SMSYcmoTDVZrJigz Subject: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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, 23 Apr 2013 12:46:10 -0000 Hi all, I incorporated the text from Michael and Donald, and added text = describing the use case that triggered this work (as has been described = on this list before). Given that these RRTypes, code-points assigned, have been implemented as = specified by at least one DNS server vendor, I have not considered = changing the presentation or encoding (or the number of) these RRTypes; = it seems counter-productive to change the spec when there is already = running code. I imagine any other related specification could proceed on = its own merits. If anybody has further suggestions for improvement (of this document, = not of RFC6895) please let me know. Joe Begin forwarded message: > From: > Subject: New Version Notification - = draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt > Date: 23 April 2013 08:36:33 EDT > To: , = , = >=20 >=20 > A new version (-03) has been submitted for = draft-jabley-dnsext-eui48-eui64-rrtypes: > = http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtype= s-03.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-jabley-dnsext-eui48-eui64-rrtypes= -03 >=20 > IETF Secretariat. >=20 From matthijs@nlnetlabs.nl Tue Apr 23 22:55:42 2013 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 6E69621F9473 for ; Tue, 23 Apr 2013 22:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sEQ2Avvxwrxh for ; Tue, 23 Apr 2013 22:55:41 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4660721F93AB for ; Tue, 23 Apr 2013 22:55:41 -0700 (PDT) Received: from [IPv6:2001:981:19be:1:8861:3604:3a45:47e3] ([IPv6:2001:981:19be:1:8861:3604:3a45:47e3]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r3O5tbYT087883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 07:55:38 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r3O5tbYT087883 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1366782939; bh=CqsUUUDhvREGx8LjGEtlJk7v1fEZxRFOTWDep+y7kd0=; h=Date:From:To:Subject:References:In-Reply-To; b=qEXZ5rEZkEVGAnAJgS+J9gzrQ2JgWeh1L5aBbjxKw4VC6AKUkZ5+PB+dv2WoS6B0g EhEYYCWRePvyROp8Crx5vqEWCVMWNp1h1x5hrtflebSCsRHbxa8EU/3q83dAYNRd/w WVMKgXMY62B2YSvJXqt74VgQoPcM9yhYTKIJZlfk= Message-ID: <517773D9.9030501@nlnetlabs.nl> Date: Wed, 24 Apr 2013 07:55:37 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> In-Reply-To: <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 24 Apr 2013 07:55:39 +0200 (CEST) Subject: Re: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 05:55:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe, On 04/23/2013 02:46 PM, Joe Abley wrote: > Hi all, > > I incorporated the text from Michael and Donald, and added text > describing the use case that triggered this work (as has been > described on this list before). > > Given that these RRTypes, code-points assigned, have been > implemented as specified by at least one DNS server vendor, I have > not considered changing the presentation or encoding (or the number > of) these RRTypes; it seems counter-productive to change the spec > when there is already running code. I imagine any other related > specification could proceed on its own merits. The RRtypes may be implemented, but no such code has been officially released. Before releasing, the specification should be stable (and if we did, we would disable it by default and mark it experimental). Therefore, I do not see this as an argument not to make changes in the presentation or encoding of the RRtypes. If such changes are made, we can quite easily adapt the code. Best regards, Matthijs > > If anybody has further suggestions for improvement (of this > document, not of RFC6895) please let me know. > > > Joe > > Begin forwarded message: > >> From: Subject: New Version >> Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt >> Date: 23 April 2013 08:36:33 EDT To: , >> , >> >> >> >> A new version (-03) has been submitted for >> draft-jabley-dnsext-eui48-eui64-rrtypes: >> http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt >> >> >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ >> >> >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-03 >> >> >> >> IETF Secretariat. >> > > _______________________________________________ dnsext mailing list > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRd3PZAAoJEA8yVCPsQCW5A8UIAL0EaJBffp2XjsIxS4c3ibKm z+2wxJESirb5BbKhMMBEIbZ8cLIspOx8Uhk7G+TqVnZlInRdES0YBwY+2ptdIOrB bKZHOAb601CtHBeYrfVl//JYR1waFQNbErtlpjLUcioNTWbG1Ho/AfCOA4VgMIOS hQoOP31ZtNjTxlgsTwyS5GDp1KgSrMgHqOGaWfeRj8muBIFdxR3Pik5ktaIIodsN GoXUHwBebci0ghvoJ4iopAJ8Cw5IrcuiKxh0lO5H9OnUeN2MPs96Mb+chR7GFovC ZjDhjeiymbO+0nh4+MTp7Fj5FC5tCu48rA2ebCdzQhbvtWWoBu8G/2C9Gp4NCwE= =Ho5z -----END PGP SIGNATURE----- From jabley@hopcount.ca Wed Apr 24 07:18:40 2013 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 BBA2921F931E for ; Wed, 24 Apr 2013 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 2LYsn2ma2C6A for ; Wed, 24 Apr 2013 07:18:40 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id B816821F8E79 for ; Wed, 24 Apr 2013 07:18:39 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so1227326qen.37 for ; Wed, 24 Apr 2013 07:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=PBL2QvJiBd25q1Wpz1610giSV9RXEhIEQ0i0Xxzp9YY=; b=CXVOc552Kb2XeylKccdAqIxObZwa1B7MMS0n5PXnglgC6lcWcFriW2oJo9KYn/ZS2h OAalZFkhhqbXHTtAJF1cXIWEAgVV05kidFMQJBwEKNqrpN90quVyzBqBbyAKXdzMhoxs V6TwSDiSpNIKgVies6kvD/3V5P7gtGZf49Wvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=PBL2QvJiBd25q1Wpz1610giSV9RXEhIEQ0i0Xxzp9YY=; b=Pf2gkVThmBitQ6bSqkuLwcRTqcj/3IrZwALiWr3F5v8QJy8kKXU+1/MgSiKiTZZZR6 7LxnC/zs4SIubjqxdQPzLSa7ghcC90v7BRl+CtEYey03O1Pl5UzgrymPwqQaGKmEQiOO CEA6uJ5y5g2yStz0T84QzDfGDjLXU8DNnXCQNSXBi+OAz/ZD/yZFXahr5sdhWPoSTVuf h7LjFm4KWcWKB/Em6Z1dPqNCNK3t8Hozi5ju9kkMynd3UHVHTJ9yIIgJk0y/CcOXT2z0 cm91Km3MaXBUSuSn0eE1x8QgGQGAz1qW/Eb2P/bDF8E0ehExEUHUgXiPH2m5FMz+MDqr 8LEQ== X-Received: by 10.229.115.30 with SMTP id g30mr7079167qcq.100.1366813119169; Wed, 24 Apr 2013 07:18:39 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:2870:eb9c:49e4:bfe2? ([2001:4900:1042:100:2870:eb9c:49e4:bfe2]) by mx.google.com with ESMTPSA id bc5sm4111656qeb.3.2013.04.24.07.18.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 07:18:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E53E7518-84DA-4C74-9D52-808FA4F3C646"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <517773D9.9030501@nlnetlabs.nl> Date: Wed, 24 Apr 2013 10:18:34 -0400 Message-Id: <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> To: Matthijs Mekking X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk5+oJEq3DOXi3sZWTYXTJ6dhUtGyo/ZZxBszidru3Saio5dkFe9ArlpgKx/eOmWjjJgBiy Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 14:18:40 -0000 --Apple-Mail=_E53E7518-84DA-4C74-9D52-808FA4F3C646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Matthijs, On 2013-04-24, at 01:55, Matthijs Mekking wrote: > On 04/23/2013 02:46 PM, Joe Abley wrote: >=20 > > Given that these RRTypes, code-points assigned, have been > > implemented as specified by at least one DNS server vendor, I have > > not considered changing the presentation or encoding (or the number > > of) these RRTypes; it seems counter-productive to change the spec > > when there is already running code. I imagine any other related > > specification could proceed on its own merits. >=20 > The RRtypes may be implemented, but no such code has been officially > released. Before releasing, the specification should be stable (and if > we did, we would disable it by default and mark it experimental). True; although I still think it's cleaner to leave the wire format alone = now that there is running code, I agree that the running code is = probably not actually running anywhere yet and the cost of changing the = spec is therefore not high. Several alternatives occur to me, some suggested by others here (e.g. = Ohta-san), e.g. 1. A single EUI RRType that includes some number of bits to identify the = type of EUI address (EUI-48 and EUI-64, currently), the remaining = payload dependant on those bits. 2. A single IEEE RRType that includes perhaps a larger number of bits to = accommodate other types of IEEE identifier, perhaps with an attendant = registry to allow future use of the RRType to be defined in an = extensible way. 3. Presentation formats that hide the details from sight, e.g. interpret = example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 address and set the = address type bits implicitly, whereas example. $ttl IN EUI = 88-99-aa-bb-cc-dd-ee-ff is clearly an EUI-64 address. There is an argument that being able to publish both EUI-48 and EUI-64 = addresses for the same owner name is more efficient if it can be done in = a single RRSet. However, I don't see any examples of networked devices = that use both EUI-48 and EUI-64 addresses simultaneously on the same = interface; each address type seems to be used by different network types = (e.g. EUI-48 for ethernet, EUI-64 for firewire) and I haven't seen any = examples of shared use. Given the lack of motivation to preserve RRTypes (according to the = current allocation rules, don't shoot the messenger) and the lack of = obvious examples of other IEEE addresses that might be useful to encode = (EUI-64 is already pretty marginal) I tend to think that the spec as = written has the benefit of simplicity and clarity, and complicating it = has little short- or long-term benefit for implementers or users. It's arguable I guess that the current spec is also more consistent in = approach with A and AAAA, in the sense that we didn't overload a single = RRType to accommodate multiple address types for IP addresses. I realise = that's more an accident of history than a conscious design decision for = A/AAAA (and one that some people wish was different). I feel like a lot of mailing list bandwidth has already been expended on = what is frankly a fairly small-time application, but if there's = consensus here that the spec should be overhauled I can do that = regardless of whether the process demands it (my impression is it = doesn't; this is not a working group document and the allocation = procedure doesn't actually require an RFC to be published at all). Joe= --Apple-Mail=_E53E7518-84DA-4C74-9D52-808FA4F3C646 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.19 (Darwin) iEYEARECAAYFAlF36boACgkQNI8MvYZSOixb0wCfc71awd2kzK5FkBwj/hjNhHR6 j8YAoKVrKBXUW345VoHwdYFx/nVoN7MA =I3bu -----END PGP SIGNATURE----- --Apple-Mail=_E53E7518-84DA-4C74-9D52-808FA4F3C646-- From alex@alex.org.uk Wed Apr 24 07:34:03 2013 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 1DD2D21F930E for ; Wed, 24 Apr 2013 07:34:03 -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 1vHsj1ou8CFk for ; Wed, 24 Apr 2013 07:34:02 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id B85D521F9354 for ; Wed, 24 Apr 2013 07:33:59 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id 124AEC561A0; Wed, 24 Apr 2013 15:33:43 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> Date: Wed, 24 Apr 2013 15:33:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07A61C09-79BF-492D-A32F-1F53C78F94D0@alex.org.uk> References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1085) Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 14:34:03 -0000 On 24 Apr 2013, at 15:18, Joe Abley wrote: > 3. Presentation formats that hide the details from sight, e.g. = interpret example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 address = and set the address type bits implicitly, whereas example. $ttl IN EUI = 88-99-aa-bb-cc-dd-ee-ff is clearly an EUI-64 address. If you are going for economy, I would have thought the most economical = would be one byte representing the length of the string, then the actual = bytes in binary format (in wire format). Obviously hyphens (or colons = for that matter) can be used in the presentation format. --=20 Alex Bligh From paul.hoffman@vpnc.org Wed Apr 24 07:43:00 2013 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 B3C9021F9350 for ; Wed, 24 Apr 2013 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Wqm72vV5YiHo for ; Wed, 24 Apr 2013 07:43:00 -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 56DB521F8E7A for ; Wed, 24 Apr 2013 07:43:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3OEguCm093326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Apr 2013 07:42:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> Date: Wed, 24 Apr 2013 07:42:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: DNSEXT Working Group Subject: Re: [dnsext] New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 14:43:00 -0000 This is amazing overkill. RRtypes are not a scarce resource; the WG = already decided that, regardless of the fact that some people forgot it. = Having different types for different lengths makes the processing code = easier; combining them with some in-record logic makes it harder. Having the WG second-guess the expert reviewer is not a good use of = anyone's time. --Paul Hoffman= From jim@rfc1035.com Wed Apr 24 07:56:11 2013 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 F019A21F92B2 for ; Wed, 24 Apr 2013 07:56:11 -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 m1yqFUmISLia for ; Wed, 24 Apr 2013 07:56:11 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6C59F21F91BC for ; Wed, 24 Apr 2013 07:56:11 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [IPv6:2001:4b10:100:7::42]) by shaun.rfc1035.com (Postfix) with ESMTP id 3C7BBCBC41F; Wed, 24 Apr 2013 15:56:10 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Wed, 24 Apr 2013 15:56:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: DNSEXT Working Group Subject: Re: [dnsext] New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 14:56:12 -0000 On 24 Apr 2013, at 15:42, Paul Hoffman wrote: > Having the WG second-guess the expert reviewer is not a good use of = anyone's time. +1 From sm@elandsys.com Tue Apr 23 15:14:01 2013 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 E162B21F9603; Tue, 23 Apr 2013 15:14:01 -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 VNGy0belbBkj; Tue, 23 Apr 2013 15:14:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F023121F95FD; Tue, 23 Apr 2013 15:14:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NMDitm000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 15:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366755240; bh=EParNmEN1TE6CBdYRcY2umSS2BtDMmAHhgCq3DxR2Os=; h=Date:To:From:Subject:Cc; b=qyI7+gg2F/GiKWagsQlM9EtOL7kjyGi19En+RBND0RMmpH7r5vvkDedlLDICf4vl+ MlrBXhN2LvlhaMfB0t14hTDjVCzyqVQ3c/te8w1kosh+2kCx8EOYjDDQmVVydgCHVg Fq4fBlGmJ6X0YuWQ/bRispF0pkMlWHE3QUidIJAM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366755240; i=@elandsys.com; bh=EParNmEN1TE6CBdYRcY2umSS2BtDMmAHhgCq3DxR2Os=; h=Date:To:From:Subject:Cc; b=1eX5jA7a7W33hcthr19xfkUiUT6s9o4OsoJz7XkFMsarw6GUNAzxBHcs+yI66lNOr TtxbJvU/pR2lu7ntfJbfCjqDfodBljHrW99Lh66vynnhwS0YNuUmESDr8pxd1vcbE0 aALFFy+aWzNkeSXPxZf/0lxbtBirbB/l6z4lINjY= Message-Id: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 15:03:45 -0700 To: dnsext@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 24 Apr 2013 08:08:38 -0700 Cc: spfbis@ietf.org Subject: [dnsext] Obsoleting SPF RRTYPE 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, 23 Apr 2013 22:14:02 -0000 Hello, Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: 'IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry.' Is the annotation in the DNS Parameters registry correct? Regards, S. Moonesamy (as document shepherd) From wwwrun@rfc-editor.org Wed Apr 24 07:26:59 2013 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 4E63921F9195 for ; Wed, 24 Apr 2013 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, 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 xJY7D1UXFDLx for ; Wed, 24 Apr 2013 07:26:58 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14E21F9104 for ; Wed, 24 Apr 2013 07:26:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 19DE0B1E002; Wed, 24 Apr 2013 07:26:49 -0700 (PDT) To: joao@bondis.org, explorer@flame.org, vixie@isc.org, brian@innovationslab.net, ted.lemon@nominum.com, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20130424142649.19DE0B1E002@rfc-editor.org> Date: Wed, 24 Apr 2013 07:26:49 -0700 (PDT) X-Mailman-Approved-At: Wed, 24 Apr 2013 08:08:38 -0700 Cc: dnsext@ietf.org, ogud@ogud.com, rfc-editor@rfc-editor.org Subject: [dnsext] [Editorial Errata Reported] RFC6891 (3604) 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, 24 Apr 2013 14:26:59 -0000 The following errata report has been submitted for RFC6891, "Extension Mechanisms for DNS (EDNS(0))". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6891&eid=3604 -------------------------------------- Type: Editorial Reported by: Olafur Gudmundsson Section: 9.1 Original Text ------------- 9.1. OPT Option Code Allocation Procedure OPT Option Codes are assigned by Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. Corrected Text -------------- 9.1. DNS EDNS0 Option Code Changes This document modifies the name of the existing registry DNS EDNS0 Options to DNS EDNS0 Option Codes (OPT) and updates the registration procedures to Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided. Notes ----- In the publication process fixing this one minor mistake in clarifying the name of the registry fell through the cracks, the consequence of this is that IANA needs this errata to clarify the registry name. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6891 (draft-ietf-dnsext-rfc2671bis-edns0-10) -------------------------------------- Title : Extension Mechanisms for DNS (EDNS(0)) Publication Date : April 2013 Author(s) : J. Damas, M. Graff, P. Vixie Category : INTERNET STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From d3e3e3@gmail.com Wed Apr 24 08:40:56 2013 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 D2C8221F93BC for ; Wed, 24 Apr 2013 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 NDOJN4tNnXNk for ; Wed, 24 Apr 2013 08:40:56 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA87621F93A3 for ; Wed, 24 Apr 2013 08:40:55 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so1826657oah.35 for ; Wed, 24 Apr 2013 08:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=wU+hlLhmbePZMBXfqcfrkS0psPrMnezhRDW4KDl2Jpo=; b=ojYYlMtvpetX01jh27BdyvdJJcJb5jeVNcdNAXny19W88rMElyFRv8+Tw0m54CqOy5 tdJD1J8tia7Xpo5FCs1SSEbG//K35SX5PLLCjQdwJ2I+szaYoQoC7Woa3PtInjN8cqjV FPYqZPcFv9kopHKS6/5TUTklLTRnSfzxZW9X8+O1K5YfoSdmDxQOBAMtkAy3Q3HMevea 8OphM7wY2VO0tGCHqrols1jDd/Jj2vwxh450EkKpxeBYNRN/Lj4Tzt+EXwcQhQVrJco7 1m3mGFUDWJ0LCBn9kAW3v9Y0KLBvcReNucHYabVBQnf0cmBhFoSHYwvbbSKEYHC23NhY 4tBg== X-Received: by 10.60.132.196 with SMTP id ow4mr14123673oeb.75.1366818055513; Wed, 24 Apr 2013 08:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Wed, 24 Apr 2013 08:40:35 -0700 (PDT) In-Reply-To: <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> From: Donald Eastlake Date: Wed, 24 Apr 2013 11:40:35 -0400 Message-ID: To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 15:40:56 -0000 I think the currently allocated two RRTYPEs are just fine. There are no network interfaces that I am aware of that have both 48 and 64 bit MAC addresses. While 48-bit is more commonly used in standards, some uses of 64 could end up being very numerous, such as 802.15 sensor devices and the like. 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 On Wed, Apr 24, 2013 at 10:18 AM, Joe Abley wrote: > Hi Matthijs, > > On 2013-04-24, at 01:55, Matthijs Mekking wrote: > >> On 04/23/2013 02:46 PM, Joe Abley wrote: >> >> > Given that these RRTypes, code-points assigned, have been >> > implemented as specified by at least one DNS server vendor, I have >> > not considered changing the presentation or encoding (or the number >> > of) these RRTypes; it seems counter-productive to change the spec >> > when there is already running code. I imagine any other related >> > specification could proceed on its own merits. >> >> The RRtypes may be implemented, but no such code has been officially >> released. Before releasing, the specification should be stable (and if >> we did, we would disable it by default and mark it experimental). > > True; although I still think it's cleaner to leave the wire format alone = now that there is running code, I agree that the running code is probably n= ot actually running anywhere yet and the cost of changing the spec is there= fore not high. > > Several alternatives occur to me, some suggested by others here (e.g. Oht= a-san), e.g. > > 1. A single EUI RRType that includes some number of bits to identify the = type of EUI address (EUI-48 and EUI-64, currently), the remaining payload d= ependant on those bits. > > 2. A single IEEE RRType that includes perhaps a larger number of bits to = accommodate other types of IEEE identifier, perhaps with an attendant regis= try to allow future use of the RRType to be defined in an extensible way. > > 3. Presentation formats that hide the details from sight, e.g. interpret = example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 address and set the add= ress type bits implicitly, whereas example. $ttl IN EUI 88-99-aa-bb-cc-dd-e= e-ff is clearly an EUI-64 address. > > There is an argument that being able to publish both EUI-48 and EUI-64 ad= dresses for the same owner name is more efficient if it can be done in a si= ngle RRSet. However, I don't see any examples of networked devices that use= both EUI-48 and EUI-64 addresses simultaneously on the same interface; eac= h address type seems to be used by different network types (e.g. EUI-48 for= ethernet, EUI-64 for firewire) and I haven't seen any examples of shared u= se. > > Given the lack of motivation to preserve RRTypes (according to the curren= t allocation rules, don't shoot the messenger) and the lack of obvious exam= ples of other IEEE addresses that might be useful to encode (EUI-64 is alre= ady pretty marginal) I tend to think that the spec as written has the benef= it of simplicity and clarity, and complicating it has little short- or long= -term benefit for implementers or users. > > It's arguable I guess that the current spec is also more consistent in ap= proach with A and AAAA, in the sense that we didn't overload a single RRTyp= e to accommodate multiple address types for IP addresses. I realise that's = more an accident of history than a conscious design decision for A/AAAA (an= d one that some people wish was different). > > I feel like a lot of mailing list bandwidth has already been expended on = what is frankly a fairly small-time application, but if there's consensus h= ere that the spec should be overhauled I can do that regardless of whether = the process demands it (my impression is it doesn't; this is not a working = group document and the allocation procedure doesn't actually require an RFC= to be published at all). > > > Joe > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From drc@virtualized.org Wed Apr 24 08:48:46 2013 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 F2BE921F9418 for ; Wed, 24 Apr 2013 08:48:45 -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 NgTU4bH1+cCD for ; Wed, 24 Apr 2013 08:48:45 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C821F9350 for ; Wed, 24 Apr 2013 08:48:44 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 0F8A817166; Wed, 24 Apr 2013 15:48:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Wed, 24 Apr 2013 08:48:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28D1FE92-D5BF-4A0E-A8E9-22D5A9AA9A4D@virtualized.org> References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: DNSEXT Working Group Subject: Re: [dnsext] New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 15:48:46 -0000 Paul, On Apr 24, 2013, at 7:42 AM, Paul Hoffman wrote: > This is amazing overkill. RRtypes are not a scarce resource; the WG = already decided that, regardless of the fact that some people forgot it. = Having different types for different lengths makes the processing code = easier; combining them with some in-record logic makes it harder. Don't have a strong opinion here (to put it mildly) and haven't really = been following, but:, what's the typical use case? Naively, I would've = have thought the client would wand to ask "what's the MAC" and get back = the EUI, be it 48 or 64. By using separate RR types, the client will = have to know if the EUI is one size or the other or it'll need to send 2 = queries. BTW, I just tried to pull down the draft and I got: "Content generation failed (on script line 329) with error code 1" with = a 404. The HTMLized version of the doc ends at section 6. > Having the WG second-guess the expert reviewer is not a good use of = anyone's time. To be clear, I'm not second-guessing the expert reviewer, rather I'm = second guessing Joe :) Regards, -drc From jabley@hopcount.ca Wed Apr 24 09:05:29 2013 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 9EED921F8B07 for ; Wed, 24 Apr 2013 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 dir6k6Q4ijj0 for ; Wed, 24 Apr 2013 09:05:28 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0321F89DB for ; Wed, 24 Apr 2013 09:05:28 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r11so1221229pdi.35 for ; Wed, 24 Apr 2013 09:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=MZAM3L+FSnP1pnJJbmxy3NjO7YSlF8301OuGjLlCweM=; b=OdF3DX2wnt5tHxGywcToGVdxbZgyVcAUUSzNaQEtrvXsh6uWYHHthObZlZL4VRFXqM mPSpHAexKRjZrU0k8mc2drV6WRbm+cTI71jnzeybklEEDuXcdN7UpqBjsy2D/2WCj96B uwszWAMzKLWzsPzn9nJj3iJDaOOu6Q1OfcTYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=MZAM3L+FSnP1pnJJbmxy3NjO7YSlF8301OuGjLlCweM=; b=jcXeQQYRPWF0DJkOShBdG8N3VD0ByTwU9HT9edtCKczSwVziOoWTko9yhsuQWnJTra +vKZHYMx6J2n0Nz2n3WVsYGnQoIhHyupcvylWLtkjzmy+ViT00zorbvl+V1N00H4PtwA E6wFHhcfeSAkWIOwnj30o5c4d3mb3M2wn6wVioqzDcjLE1TrCSkd+eG3mNCDTnmgZGFO RSmCymSy/dx34kzz+aDV8QvRaDZvmHs+nlI9l7KRTSlzeFstoWmPI+YFRLIeI5rGrEjl /sxs7+CF9E4WaJLRiSeURKuuGbH90MFnbNOacdleNO/F+Ey4HP4TTjen+svb9Qv5cu1X K6iA== X-Received: by 10.66.150.35 with SMTP id uf3mr20273659pab.34.1366819528429; Wed, 24 Apr 2013 09:05:28 -0700 (PDT) Received: from [199.212.90.33] ([199.212.90.33]) by mx.google.com with ESMTPSA id dr4sm3563114pbb.19.2013.04.24.09.05.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:05:27 -0700 (PDT) References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> <28D1FE92-D5BF-4A0E-A8E9-22D5A9AA9A4D@virtualized.org> Mime-Version: 1.0 (1.0) In-Reply-To: <28D1FE92-D5BF-4A0E-A8E9-22D5A9AA9A4D@virtualized.org> Content-Type: multipart/alternative; boundary=Apple-Mail-CF462102-FFFB-4777-BE43-7CC327DE4C93 Content-Transfer-Encoding: 7bit Message-Id: <7704A464-F6D8-424D-806E-FE69F0A8AAE7@hopcount.ca> X-Mailer: iPad Mail (10B329) From: Joe Abley Date: Wed, 24 Apr 2013 12:05:24 -0400 To: David Conrad X-Gm-Message-State: ALoCoQlE0Z8xLO5vknK7dhHRhOgqB19P66Zo5k+/t1v5GzT4EeebdLB2xQuAmUSHnQaqu6NEFS6U Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Wed, 24 Apr 2013 16:05:29 -0000 --Apple-Mail-CF462102-FFFB-4777-BE43-7CC327DE4C93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 2013-04-24, at 11:48, David Conrad wrote: > On Apr 24, 2013, at 7:42 AM, Paul Hoffman wrote: >> This is amazing overkill. RRtypes are not a scarce resource; the WG alrea= dy decided that, regardless of the fact that some people forgot it. Having d= ifferent types for different lengths makes the processing code easier; combi= ning them with some in-record logic makes it harder. >=20 > Don't have a strong opinion here (to put it mildly) and haven't really bee= n following, but:, what's the typical use case? Naively, I would've have th= ought the client would wand to ask "what's the MAC" and get back the EUI, be= it 48 or 64. By using separate RR types, the client will have to know if t= he EUI is one size or the other or it'll need to send 2 queries. No idea what a typical use case would be. The use case that led to the think= ing that led to the draft is described in -03. > BTW, I just tried to pull down the draft and I got: >=20 > "Content generation failed (on script line 329) with error code 1" with a 4= 04. >=20 > The HTMLized version of the doc ends at section 6. For me, too. The text version is complete: http://tools.ietf.org/id/draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt > To be clear, I'm not second-guessing the expert reviewer, rather I'm secon= d guessing Joe :) Fair enough, too :-) Joe= --Apple-Mail-CF462102-FFFB-4777-BE43-7CC327DE4C93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 2013-04-24, at 11:48, David Conrad &= lt;drc@virtualized.org> wrote:=

On Apr 24, 2013, a= t 7:42 AM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
This= is amazing overkill. RRtypes are not a scarce resource; the WG already deci= ded that, regardless of the fact that some people forgot it. Having differen= t types for different lengths makes the processing code easier; combining th= em with some in-record logic makes it harder.
<= /span>
Don't have a strong opinion here (to put it mildly) and have= n't really been following, but:, what's the typical use case?  Naively,= I would've have thought the client would wand to ask "what's the MAC" and g= et back the EUI, be it 48 or 64.  By using separate RR types, the clien= t will have to know if the EUI is one size or the other or it'll need to sen= d 2 queries.

No idea what a= typical use case would be. The use case that led to the thinking that led t= o the draft is described in -03.

BTW, I just tried to pull down the draft and I got:
"Content generation failed (on script line 329) wit= h error code 1" with a 404.

The HTMLized ve= rsion of the doc ends at section 6.

To be clear, I'm= not second-guessing the expert reviewer, rather I'm second guessing Joe :)<= /span>

Fair enough, too :-)
<= div>

Joe
= --Apple-Mail-CF462102-FFFB-4777-BE43-7CC327DE4C93-- From envite@rolamasao.org Wed Apr 24 16:30:04 2013 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 595A321F896B for ; Wed, 24 Apr 2013 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH9APS5p3Lw0 for ; Wed, 24 Apr 2013 16:30:03 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id D093021F8A48 for ; Wed, 24 Apr 2013 16:30:02 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 8CB7D11EAB for ; Thu, 25 Apr 2013 00:30:00 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Thu, 25 Apr 2013 00:29:56 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3594534.QsJ1jk3Fco"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201304250029.57132.envite@rolamasao.org> Subject: [dnsext] Draft for OID 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, 24 Apr 2013 23:30:04 -0000 --nextPart3594534.QsJ1jk3Fco Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all Draft for DNS-like OID system has been submitted: https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/ Please comment on it. Do not hesitate to be harsh if needed. Thanks Noel Torres er Envite ------------------------- A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart3594534.QsJ1jk3Fco Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlF4avUACgkQcLQA8+7Hw3KOAwCfT5y+7+nIuuYYkExWaD1Om57k vaQAnAjIBs1/pAcMTyxMXsczDuxf+WMe =fHey -----END PGP SIGNATURE----- --nextPart3594534.QsJ1jk3Fco-- From drc@virtualized.org Wed Apr 24 17:12:11 2013 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 19A0B21F8EF2; Wed, 24 Apr 2013 17:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt20y-psRfit; Wed, 24 Apr 2013 17:12:10 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5E721F8D29; Wed, 24 Apr 2013 17:12:09 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 0790A17166; Thu, 25 Apr 2013 00:12:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Date: Wed, 24 Apr 2013 17:12:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 00:12:11 -0000 Hi, On Apr 23, 2013, at 3:03 PM, S Moonesamy wrote: > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: >=20 > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >=20 > Is the annotation in the DNS Parameters registry correct? It is in keeping with past practice, e.g., see the notations for MD, MF, = A6, and the MAILA RRtypes at = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml. I personally believe deprecating the SPF RR is the wrong way to go, but = I'm guessing that discussion has already been had. Regards, -drc From marka@isc.org Wed Apr 24 17:28:59 2013 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 2EFDC21F902A; Wed, 24 Apr 2013 17:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH3vPuWFtwja; Wed, 24 Apr 2013 17:28:58 -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 8DDC321F8CE9; Wed, 24 Apr 2013 17:28:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 85198C94B0; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366849738; bh=KwbHRjok2cIbiGh7i5h5xzGj8FmWwoiwj1z7CxPrz0Y=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Cm5sB1uQs5r3L3Iatn28pkQMvI7BhuvMjMkpIafYE5HfQ4zyDUfpyW0R2Tx/muAA5 EOvWRmjjdKJ1GT1JSeTDVbbAfFYOMqjSLWCOioOUOYsf9XRChNMEliV+wI/apejUxs moWCgc/s9hE2RsPeir9yD0gk10WgxvhyJhoUlm54= 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; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c864:9043:57a3:304b]) (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 46C2B216C40; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2F41B32F308D; Thu, 25 Apr 2013 10:28:47 +1000 (EST) To: David Conrad From: Mark Andrews References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> In-reply-to: Your message of "Wed, 24 Apr 2013 17:12:07 -0700." <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> Date: Thu, 25 Apr 2013 10:28:47 +1000 Message-Id: <20130425002847.2F41B32F308D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org, S Moonesamy , dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 00:28:59 -0000 In message <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org>, David Conrad writes: > Hi, > > On Apr 23, 2013, at 3:03 PM, S Moonesamy wrote: > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > > > Is the annotation in the DNS Parameters registry correct? > > It is in keeping with past practice, e.g., see the notations for MD, MF, A6, > and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-p > arameters.xml. > > I personally believe deprecating the SPF RR is the wrong way to go, but I'm g > uessing that discussion has already been had. > > Regards, > -drc Personally, I agree with you. TXT to SPF transition was always going to be a slow transition. libspf2 took ages to come out but it is out now and looks for SPF records first. Waiting less than is single hardware deprecation cycle before stating that the transition is not working wasn't a good faith effort. The introduction of MX records to 10 or more years before you could reliably have MX only (no A records) domains. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Wed Apr 24 18:33:42 2013 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 3526D21F8DCF for ; Wed, 24 Apr 2013 18:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 W1e2BBDwQgKn for ; Wed, 24 Apr 2013 18:33:41 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 13EAE21F8D90 for ; Wed, 24 Apr 2013 18:33:40 -0700 (PDT) Received: (qmail 96340 invoked from network); 25 Apr 2013 01:33:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2013 01:33:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517887f4.xn--9vv.k1304; i=johnl@user.iecc.com; bh=S6sC1ODxnUvcyNKwp/d1eV69Eld3Nif3nI26982ZXFg=; b=GK4VzpzZjXQ6u36B9nstjlzaM6J3lqA3KnUOAPF4rMO8iRes60z2t38PpowV/U/cP2le3RBkGdLyaENCN9SvPiIV2nryI95lqgylwX+sxXRvgZr3IcMM4SpWHotW1SXmcUfwU0wlekE05TyNj1cHXkzxJpLM2OL5WeGO2AH5F4Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517887f4.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=S6sC1ODxnUvcyNKwp/d1eV69Eld3Nif3nI26982ZXFg=; b=klT9TIghyA8EUg2ahTQZPh0g8qfAf8jCTBfVH0falo+1xQbEZyMVWtCumt42uKxNS6h3Y/bGffSZUw8tHkZWpV+Fuh4g1jb5DUcE9Sfr3WWCjQhtG0GFpdXJLpW1J+LevzRnD98izZSKMEMllgC3bbZ1LGQp8N3wXNj2m6o0tLU= Date: 25 Apr 2013 01:33:17 -0000 Message-ID: <20130425013317.36729.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130425002847.2F41B32F308D@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 01:33:42 -0000 >> I personally believe deprecating the SPF RR is the wrong way to go, but I'm >> guessing that discussion has already been had. Yes, it has. Did you miss RFC 6686? Once again, the huge practical barriers to deploying new RRTYPEs made the SPF RR dead on arrival. R's, John From drc@virtualized.org Wed Apr 24 19:34:25 2013 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 A2F8721F85C0 for ; Wed, 24 Apr 2013 19:34:25 -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 3+02ygyirzMk for ; Wed, 24 Apr 2013 19:34:24 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7F52221F8539 for ; Wed, 24 Apr 2013 19:34:24 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B4D5F17166; Thu, 25 Apr 2013 02:34:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <20130425013317.36729.qmail@joyce.lan> Date: Wed, 24 Apr 2013 19:34:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 02:34:25 -0000 John, On Apr 24, 2013, at 6:33 PM, John Levine wrote: >>> I personally believe deprecating the SPF RR is the wrong way to go, = but I'm >>> guessing that discussion has already been had. > Yes, it has. Did you miss RFC 6686? I've read it. Didn't strike me as particularly persuasive towards = deprecating the SPF RR, but that's probably just me. > Once again, the huge practical barriers to deploying new RRTYPEs made = the SPF RR dead on arrival. Yes, the ossification of the DNS makes introducing new things = challenging however as Mark pointed out, software was beginning to do = the right thing and there actually are web interfaces out there that let = folks enter SPF records (I use one). My reading of 6686 would suggest = that SPF has greater penetration than either DNSSEC or IPv6 which both = face the practical barriers you mention, yet I'd argue deploying DNSSEC = and IPv6 are the right thing to do. In any event, I suppose that's what last call is for. Regards, -drc From mohta@necom830.hpcl.titech.ac.jp Wed Apr 24 19:41:04 2013 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 385E021F8C08 for ; Wed, 24 Apr 2013 19:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 qXEV1UZFIzhR for ; Wed, 24 Apr 2013 19:41:03 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id A130E21F899E for ; Wed, 24 Apr 2013 19:41:02 -0700 (PDT) Received: (qmail 33147 invoked from network); 25 Apr 2013 02:38:39 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 25 Apr 2013 02:38:39 -0000 Message-ID: <51789755.3060803@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Apr 2013 11:39:17 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> In-Reply-To: <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 02:41:04 -0000 David Conrad wrote: > My reading of 6686 would suggest that SPF has greater > penetration than either DNSSEC or IPv6 which both face the > practical barriers you mention, Good point. > yet I'd argue deploying DNSSEC and IPv6 are the right thing to do. It is not. Because of so high noise level here attempting to deploy DNSSEC, we fail to join a lot of discussions on the real works. Masataka Ohta From johnl@taugh.com Wed Apr 24 20:09:48 2013 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 0ED9821F9120 for ; Wed, 24 Apr 2013 20:09:48 -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 V3GexnSMJFHz for ; Wed, 24 Apr 2013 20:09:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 336B521F8FC6 for ; Wed, 24 Apr 2013 20:09:47 -0700 (PDT) Received: (qmail 18741 invoked from network); 25 Apr 2013 03:09:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=4934.51789e7a.k1304; bh=w5JnpWx5+jiPJlbigCHrE/3Q7CPiIrbjlrUm5ipz6xc=; b=WCmBbrpZuQZW0Qszb8BSuNwphfccFT3pvvmKzA877YxuyskfrkWzaQxZbA3fIrwPV2aIRO7CufptqwOrGqeJGycZ3gmHgSoKEgOkYDHPa4Uo1DY01MoZjpxs8Yyexd2zLTL1J5XfKGJoExxOVmAcdGvdZqJYJFgvnHow0xdL5D4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=4934.51789e7a.k1304; bh=w5JnpWx5+jiPJlbigCHrE/3Q7CPiIrbjlrUm5ipz6xc=; b=L99rJjFYG0PNX5vaY/qET9h1wU4Q4uRM6Zx6kq/V73Z38RzAtOj/sdt2FxM25j8jo8AvLo81x/0PG1SE7GduZ8cTJ2wjp1yW8rJD6LauUQQgH5/54pjv7ODsIwowO+a66KU6JO68PAaE1P6lYI92E+3KleoAzqSGc6R9kL2MQX8= Received: (ofmipd 127.0.0.1); 25 Apr 2013 03:09:24 -0000 Date: 24 Apr 2013 23:09:46 -0400 Message-ID: From: "John R Levine" To: "David Conrad" In-Reply-To: <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-138796202-1366859386=:38677" Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 03:09:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-138796202-1366859386=:38677 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > In any event, I suppose that's what last call is for. It's in WGLC now. Feel free to let the WG know how you feel. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-138796202-1366859386=:38677 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MDMwOTQ2WjAjBgkqhkiG 9w0BCQQxFgQU8hJwsSrxZE1pqacDOwUFuqlJ64IweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEANRoqFa55hhQ8 cUtgowgAQP7lsBUuEpHGCY52Af4kjymlCWxgIPhT/L2zdRMH5Af7xD4Pilgk nhsTIBLGwZjK6uCrtCRVWB5RQRl91WtEjQy3pr1N5nJaQt8hKf1roaJSY+wu VrUbtSICveTw+VhwD2eV+URvLfCfVHDTXaCCr51HC7dzHsJ6j+gc82ew/Y9j r+6sSN7Z3etMiwO+NVU8AjkwuER4SFBIXwHsgM5CxWHHE+V0PUNG/MkWpVmI 71qY2FEmTn7RaX8j0xSSnFhDk13Kno/4sJ56nJ/R1rMxdIEVBTvRhhV7htJ9 j6jOZV2NwvHOJYUZ11M0vAWS8N5gnQ== --3825401791-138796202-1366859386=:38677-- From drc@virtualized.org Wed Apr 24 21:37:46 2013 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 1227521F93BE for ; Wed, 24 Apr 2013 21:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 neEfXVzclHzo for ; Wed, 24 Apr 2013 21:37:45 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D721F93BC for ; Wed, 24 Apr 2013 21:37:45 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 99FB317166 for ; Thu, 25 Apr 2013 04:37:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Wed, 24 Apr 2013 21:37:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> To: "dnsext@ietf.org Group" X-Mailer: Apple Mail (2.1503) Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 04:37:46 -0000 On Apr 24, 2013, at 8:09 PM, "John R Levine" wrote: >> In any event, I suppose that's what last call is for. > It's in WGLC now. Feel free to let the WG know how you feel. Thanks for the kind invitation. Actually, I'm more intrigued as to the view of the folks on DNSEXT on = this issue (I have no illusions that I'd be able to sway anyone related = to spfbis -- minds appear to be quite made up based on the private = messages I've received):=20 Draft-ietf-spfbis-4408bis-14 and RFC 6686 would appear to suggest that = the use of new RRtypes is so fraught with "practical" and operational = issues that for all intents and purposes, the definition of = Internet-wide RRtypes is a lost cause even if draft-levine-dnsextlang is = finished (I have a bit of skepticism that the same folks who can't = implement support for SPF RRs are going to implement = draft-levine-dnsextlang, but that may just be me). An implication of = this would appear to be that definition of new RRs should be = constrained to "consenting adults" (e.g., EUI48/68). Is there some other = takeaway from the "failure" of the SPF RR? Thanks, -drc From matthijs@nlnetlabs.nl Wed Apr 24 23:06:39 2013 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 2D5F921F8E6A for ; Wed, 24 Apr 2013 23:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jZ7qp5BzDJDn for ; Wed, 24 Apr 2013 23:06:38 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C30E121F86EA for ; Wed, 24 Apr 2013 23:06:37 -0700 (PDT) Received: from [IPv6:2001:981:19be:1:25f4:4884:8d01:4709] ([IPv6:2001:981:19be:1:25f4:4884:8d01:4709]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r3P66Xn0016142 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 08:06:34 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r3P66Xn0016142 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1366869995; bh=YF4OyK9J2Fxnpgw/a8lXDFpjx8PvAcxcLS66pan6hW8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=oBt2KzgUj0tYHiArs5q11gTm+taRLVP1aU5M4VYpF+phh/Q4ryQJVC8FIwTA89Bot rgOR/vieWGANajfp7m3jZ/RnHdV67qSC2jyexQNRSQBINqxlkjNb8D5izA9l1rFgf/ wGdyqhF4tQ24f4kCkcTPm8z7x3W2xJPo959a8qeA= Message-ID: <5178C7E8.80903@nlnetlabs.nl> Date: Thu, 25 Apr 2013 08:06:32 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joe Abley References: <20130423123633.28301.36321.idtracker@ietfa.amsl.com> <4BBCB100-0E28-462F-8557-64ADB97F6E2E@hopcount.ca> <517773D9.9030501@nlnetlabs.nl> <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> In-Reply-To: <2ECD46C7-A579-4805-9D6B-17B07AD2BA67@hopcount.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 25 Apr 2013 08:06:35 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-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: Thu, 25 Apr 2013 06:06:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe, On 04/24/2013 04:18 PM, Joe Abley wrote: > Hi Matthijs, > > On 2013-04-24, at 01:55, Matthijs Mekking > wrote: > >> On 04/23/2013 02:46 PM, Joe Abley wrote: >> >>> Given that these RRTypes, code-points assigned, have been >>> implemented as specified by at least one DNS server vendor, I >>> have not considered changing the presentation or encoding (or >>> the number of) these RRTypes; it seems counter-productive to >>> change the spec when there is already running code. I imagine >>> any other related specification could proceed on its own >>> merits. >> >> The RRtypes may be implemented, but no such code has been >> officially released. Before releasing, the specification should >> be stable (and if we did, we would disable it by default and mark >> it experimental). > > True; although I still think it's cleaner to leave the wire format > alone now that there is running code, I agree that the running code > is probably not actually running anywhere yet and the cost of > changing the spec is therefore not high. It may be cleaner, true, but if there is a good proposal to change the wire format or presentation format it should not be the reason to turn such a change down. > Several alternatives occur to me, some suggested by others here > (e.g. Ohta-san), e.g. > > 1. A single EUI RRType that includes some number of bits to > identify the type of EUI address (EUI-48 and EUI-64, currently), > the remaining payload dependant on those bits. > > 2. A single IEEE RRType that includes perhaps a larger number of > bits to accommodate other types of IEEE identifier, perhaps with an > attendant registry to allow future use of the RRType to be defined > in an extensible way. > > 3. Presentation formats that hide the details from sight, e.g. > interpret example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 > address and set the address type bits implicitly, whereas example. > $ttl IN EUI 88-99-aa-bb-cc-dd-ee-ff is clearly an EUI-64 address. > > There is an argument that being able to publish both EUI-48 and > EUI-64 addresses for the same owner name is more efficient if it > can be done in a single RRSet. However, I don't see any examples of > networked devices that use both EUI-48 and EUI-64 addresses > simultaneously on the same interface; each address type seems to be > used by different network types (e.g. EUI-48 for ethernet, EUI-64 > for firewire) and I haven't seen any examples of shared use. > > Given the lack of motivation to preserve RRTypes (according to the > current allocation rules, don't shoot the messenger) and the lack > of obvious examples of other IEEE addresses that might be useful to > encode (EUI-64 is already pretty marginal) I tend to think that the > spec as written has the benefit of simplicity and clarity, and > complicating it has little short- or long-term benefit for > implementers or users. > > It's arguable I guess that the current spec is also more consistent > in approach with A and AAAA, in the sense that we didn't overload a > single RRType to accommodate multiple address types for IP > addresses. I realise that's more an accident of history than a > conscious design decision for A/AAAA (and one that some people wish > was different). > > I feel like a lot of mailing list bandwidth has already been > expended on what is frankly a fairly small-time application, but if > there's consensus here that the spec should be overhauled I can do > that regardless of whether the process demands it (my impression is > it doesn't; this is not a working group document and the allocation > procedure doesn't actually require an RFC to be published at all). I agree and I hope you realize that my previous mail was not discussing the RRtype allocation. I was merely arguing your argument for not changing the wire and presentation format. I also don't propose any changes to the format (although I do have some ideas about that), but suppose if someone did, imho your "running code" argument should not be a valid reason to deny such a change. Best regards, Matthijs > > > Joe > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJReMflAAoJEA8yVCPsQCW5TgcH/2S3VtJQ5xyMRdzNngb+7TBS gZDUEa9ON6kl8eSf5C6ehn0voM2N5nv9ersP5f5OyUK8PxVmQ7NG5op/tdNfPrWQ Tmcw69j5e9muWpItcMovjDIWZHJdh9BO+YH8/DSB0dwbxfb+zpw4M8ubKdHoz6WY IbTwYsvjy+phKWNQWlBTCRqaGYtI+qKxxXii4cF48snW56+uHjaKiPSnovlL69yg DMsrbUA9kMGOoBPD3cfoOvx7eaFRJZ+0M5OXLowtBUTYYhOXQLf+ZABYQ4PYzD0P NS9nNU5HHRy3bR9C/TidyN8iCeyXdKPcxFoCGPwtrbiVS0EnA+6YC/g4oIM8oYY= =OD7W -----END PGP SIGNATURE----- From mansaxel@besserwisser.org Thu Apr 25 00:51:51 2013 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 9CCCE21F8FCF; Thu, 25 Apr 2013 00:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1PvEUvUDWpz; Thu, 25 Apr 2013 00:51:51 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 168BF21F8E6A; Thu, 25 Apr 2013 00:51:50 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 60CE39EF0; Thu, 25 Apr 2013 09:51:47 +0200 (CEST) Date: Thu, 25 Apr 2013 09:51:47 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: David Conrad Message-ID: <20130425075147.GN23770@besserwisser.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YuJye9aIuN0w6xGV" Content-Disposition: inline In-Reply-To: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org, S Moonesamy , dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 07:51:51 -0000 --YuJye9aIuN0w6xGV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Wed, Apr 24, 2013 at 05:1= 2:07PM -0700 Quoting David Conrad (drc@virtualized.org): =20 > I personally believe deprecating the SPF RR is the wrong way to go, but I= 'm guessing that discussion has already been had. Overloading the TXT record has always been a Really Bad Idea. I'm with drc here. While the draft probably is formally proper, it advocates the worng decision and I cannot support it. OTOH, mixing up routing layer with application layer and gilding some IP addresses in favour of others is another Really Bad Idea; I'd rather throw the entire business of supposedly Good and Bad addresses out the window and start looking at the in-band data instead; ie. DKIM or similar. While removing SPF can be seen as in support of above, I'm pretty certain that it in practice just will continue as usual, in TXT records. Better=20 then that we get to keep TXT records for free-form data.=20 Regards,=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I want you to organize my PASTRY trays ... my TEA-TINS are gleaming in formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me = -- --YuJye9aIuN0w6xGV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF44JMACgkQ02/pMZDM1cUlPgCgnlUDj/ZCIF/KPgurChMzpxqA kzwAoIizScdRC7Leb10Rd+zRkWKcJK0U =RvJI -----END PGP SIGNATURE----- --YuJye9aIuN0w6xGV-- From doug.mtview@gmail.com Thu Apr 25 02:15:31 2013 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 3FD6F21F8FF2; Thu, 25 Apr 2013 02:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvOD6XoY6MR5; Thu, 25 Apr 2013 02:15:30 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90821F86CA; Thu, 25 Apr 2013 02:15:28 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id i38so2482328iae.20 for ; Thu, 25 Apr 2013 02:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=G8nBCqSXbLg2MXGb+nMQpLbL10NM3S+3zLZPVKC4Rp8=; b=qqohewri91PxM0MR0Md0lUlzXZst+APl7sYhAwqw1a+peRcyiChoAXfjDwE4Tnhp/u g8nvp9BInEKBnmH0awTojX9CXGZkJA1Op0EVllmuZlXdjMIPnjqU8qqnUTVrccROAxLz KevYwfePXogtcgJWyCe42zDW69KrsjEUPQFH5+qQCtMR35q1zuhM/fFXGird546Tqbyk HzmAI56D740u/5tskRbBHcaqvmqtyTM0aN5VVt/BIdmIcnM6om6P5cweTb++46shDqTl WaZINmAoGS3ZoaLLaBb35JjDTcOo7VENfWjltM5Ms4LbX2PWybnXZUSb/UAlz3SJLzoO l4vw== X-Received: by 10.50.128.16 with SMTP id nk16mr17840944igb.15.1366881327990; Thu, 25 Apr 2013 02:15:27 -0700 (PDT) Received: from ?IPv6:2601:9:4d80:89:21c1:6200:53b7:b135? ([2601:9:4d80:89:21c1:6200:53b7:b135]) by mx.google.com with ESMTPSA id p9sm33284379iga.7.2013.04.25.02.15.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 02:15:27 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <20130425075147.GN23770@besserwisser.org> Date: Thu, 25 Apr 2013 02:15:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0991993C-F710-4617-9333-07996AB2C700@gmail.com> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> <20130425075147.GN23770@besserwisser.org> To: =?iso-8859-1?Q?M=E5ns_Nilsson?= X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, dnsext@ietf.org, S Moonesamy Subject: Re: [dnsext] Obsoleting SPF RRTYPE and deprecate all macros 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, 25 Apr 2013 09:15:31 -0000 On Apr 25, 2013, at 12:51 AM, M=E5ns Nilsson = wrote: > Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Wed, Apr 24, 2013 at = 05:12:07PM -0700 Quoting David Conrad (drc@virtualized.org): >=20 >> I personally believe deprecating the SPF RR is the wrong way to go, = but I'm guessing that discussion has already been had. >=20 > Overloading the TXT record has always been a Really Bad Idea. I'm with > drc here. While the draft probably is formally proper, it advocates = the > worng decision and I cannot support it. >=20 > OTOH, mixing up routing layer with application layer and gilding some > IP addresses in favour of others is another Really Bad Idea; I'd = rather > throw the entire business of supposedly Good and Bad addresses out the > window and start looking at the in-band data instead; ie. DKIM or = similar. >=20 > While removing SPF can be seen as in support of above, I'm pretty = certain > that it in practice just will continue as usual, in TXT records. = Better=20 > then that we get to keep TXT records for free-form data. Dear M=E5ns, Obsoleting SPF RR is not enough. All macros should be deprecated as = well. tools.ietf.org/html/rfc3123 predates this poorly conceived = scheme. SPF was poorly conceived starting out as 2KB TXT XML encoded resource = records in DNS where many expect direct use of TXT resource records = permits wildcard replication. This scheme also expects receivers to = combine email-address local-parts with SPF domains to query other = resource record sets. SPF may induce high query overheads flooding = caches with up to 100 transactions derived from email-address = local-parts that normally vary in spam campaigns to also support DDoS = attacks leveraging receiver's attempt to verify service authorizations. (10 mechanisms x 10 (PTRs or As or AAAAs)) Permitting PTRs can also = lead to connection resource exhaustion. The macro expansion can also = leverage DNS name compression to further increase network amplifications = against some unseen domain while spamming entirely different domains. The macro scheme was not intended to validate EHLOs or provide NDN = authorizations and inappropriately exposes aspects of message handling. = The review of SPF use also neglects whether major providers process = these macros, many whom assure they do not. Verifying the ELHO is = seldom supported, where authorization permits by bulk sender's to dodge = accountability. Without genuine domain authentication SMTP is not safe. = =20 A safe and effective alternative is needed to safely provide a basis for = assessing and reacting to abusive behavior. XMPP offers examples of = StartTLS used in a highly scalable fashion that can leverage OCSP and = self published DANE Certs needed to support IPv6. =20 Regards, Douglas Otis =20 From ajs@anvilwalrusden.com Thu Apr 25 02:59:00 2013 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 7810621F94A9 for ; Thu, 25 Apr 2013 02:59:00 -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 y5h3dtYBbPg3 for ; Thu, 25 Apr 2013 02:59:00 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D2DFF21F94DF for ; Thu, 25 Apr 2013 02:58:59 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BDED68A031 for ; Thu, 25 Apr 2013 09:58:56 +0000 (UTC) Date: Thu, 25 Apr 2013 05:58:56 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130425095856.GA18148@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 09:59:00 -0000 No hat. Especially this time. On Wed, Apr 24, 2013 at 09:37:43PM -0700, David Conrad wrote: > > implication of this would appear to be that definition of new RRs > should be constrained to "consenting adults" (e.g., EUI48/68). Is > there some other takeaway from the "failure" of the SPF RR? One obvious one is, "Don't have two mechanisms to achieve the same goal." Given that SPF has the TXT record and that there is zero hope of getting rid of that use, the SPF RRTYPE was just a vain hope. And indeed, as DKIM and other such uses show, the underscore-label extension is a permanent part of the DNS landscape and we should expect applications to depend on that as often as on new RRTYPEs, regardless of any advice to the contrary. It's rather unfortunate that SPF didn't use that, but it didn't. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Ted.Lemon@nominum.com Thu Apr 25 04:13:41 2013 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 6DCCE21F9500 for ; Thu, 25 Apr 2013 04:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 JH2RG+WpbDSF for ; Thu, 25 Apr 2013 04:13:40 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id C300521F9350 for ; Thu, 25 Apr 2013 04:13:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUXkP5G6IYvcimBCbop7z37rRFwMTfjcY@postini.com; Thu, 25 Apr 2013 04:13:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A966B1B80E1 for ; Thu, 25 Apr 2013 04:13:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A1182190052; Thu, 25 Apr 2013 04:13:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 04:13:30 -0700 From: Ted Lemon To: David Conrad Thread-Topic: [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQUvZmmQ2JXTkhEy3ea4oJfG13ZjmnHmAgAAREQCAAAnkAIAAGJOAgABuk4A= Date: Thu, 25 Apr 2013 11:13:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> In-Reply-To: <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F13F4EF70F63A40B7FCBBE6762F4FB1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 11:13:41 -0000 On Apr 25, 2013, at 12:37 AM, David Conrad wrote: > I have no illusions that I'd be able to sway anyone related to spfbis -- = minds appear to be quite made up based on the private messages I've receive= d Then perhaps we should all tromp on this in IETF last call. I certainly a= gree with your take on this: the idea that a document would advocate the us= e of a TXT record because promulgating SPF records is "too hard" is just br= oken. From mohta@necom830.hpcl.titech.ac.jp Thu Apr 25 05:18:58 2013 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 4DE8921F9367 for ; Thu, 25 Apr 2013 05:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 20NLSSWWn7mx for ; Thu, 25 Apr 2013 05:18:57 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id D0A2921F9079 for ; Thu, 25 Apr 2013 05:18:56 -0700 (PDT) Received: (qmail 41999 invoked from network); 25 Apr 2013 12:16:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 25 Apr 2013 12:16:25 -0000 Message-ID: <51791EFC.5060907@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Apr 2013 21:18:04 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <20130425095856.GA18148@mx1.yitter.info> In-Reply-To: <20130425095856.GA18148@mx1.yitter.info> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 12:18:58 -0000 Andrew Sullivan wrote: >> implication of this would appear to be that definition of new RRs >> should be constrained to "consenting adults" (e.g., EUI48/68). Is >> there some other takeaway from the "failure" of the SPF RR? > > One obvious one is, "Don't have two mechanisms to achieve the same > goal." It means anything to be implemented by TXT can not have its own RR. > Given that SPF has the TXT record and that there is zero hope > of getting rid of that use, the SPF RRTYPE was just a vain hope. "there is zero hope of getting rid of that use"? Why? Some reasoning, please. > And indeed, as DKIM and other such uses show, the underscore-label > extension is a permanent part of the DNS landscape and we should > expect applications to depend on that as often as on new RRTYPEs, > regardless of any advice to the contrary. Where is the advice not to have underscore-label extensions with SRV? The problem of underscore-label extensions is that the underscore-labels is not assured to be unique (RFC1034 imposes no restriction to use underscore-label for any purpose) and can have conflicts to other applications. Thus, an application specific underscore-label extension is just fine if and only if it is tied with applications' own specific RR type to prevent ambiguities on meaning of the label. That is, having application specific RRs is MUST, even if you use underscore-labels. Masataka Ohta From ajs@anvilwalrusden.com Thu Apr 25 05:34:35 2013 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 6B60A21F87C5 for ; Thu, 25 Apr 2013 05:34:35 -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 Hkvz70zxzzsj for ; Thu, 25 Apr 2013 05:34:34 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6D05521F8AD5 for ; Thu, 25 Apr 2013 05:34:34 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CDD8F8A031 for ; Thu, 25 Apr 2013 12:34:33 +0000 (UTC) Date: Thu, 25 Apr 2013 08:34:30 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130425123430.GC18348@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 12:34:35 -0000 Dear colleagues, First, no hat, but just for context: I am co-chair of the moribund dnsext and also of spfbis. Glancing at another hat, I am acutely aware of recommendations the IAB has historically made about the use and extension of the DNS, and I mostly agree with those observations. To emphasise, however, I am speaking here in an individual capacity. This conversation should probably move to spfbis@ if we're going to have it out, but I want to make sure that people who haven't been following that WG have the appropriate context. On Thu, Apr 25, 2013 at 11:13:29AM +0000, Ted Lemon wrote: > Then perhaps we should all tromp on this in IETF last call. I certainly agree with your take on this: the idea that a document would advocate the use of a TXT record because promulgating SPF records is "too hard" is just broken. > I'm not sure whether Ted is offering advice above to a still-active WG of which he is the shepherd, or participating as an individual, but in any case I'd like to point out that the documents in question (one of which is already an RFC) don't advocate new use of TXT because another type is "too hard". There's actually an interoperability problem, and there's a simple fact of deployment. The IETF has not had notable success when it pretends to be King Canute, and I think "tromping on this" would be an example of such behaviour. First, it is worth noting three things about the co-existing SPF and TXT records described in RFC 4408. The first is that a server using SPF MUST publish at least one of them. The second is that a client using SPF MUST query for at least one of them. The third is that there was never any specification of interdependency between these records. The consequence of those three things is that there's a basic interop problem in RFC 4408: if a server only publishes SPF records and a client only looks up TXT records (or conversely), they both implement the protocol as specified and yet the communication fails. So, this is broken. Now, SPFBIS was chartered to move SPF from experimental to the standards track, on the not-implausible premises that it's a widely deployed technology and, indeed, 4408 was never really an experiment anyway. To fix the interop problem above, we have three options: 1. Specify that clients query first SPF, and then query TXT if SPF returned NODATA. 2. Specify that clients first query TXT, and then SPF if TXT returned either NODATA or a TXT record that wasn't an SPF record. 3. Deprecate one of the types. We rejected (1) (in consultation with DNSOP) on the grounds that the evidence showed overwhelmingly that deployed systems used TXT in preference to SPF. A number of systems (including, full disclosure, one of the services that my employer, Dyn, offers) to this day only support SPF using TXT records. So, (1) would result in an increase of query traffic with little, if any, benefit. We rejected (2) on the grounds that, since nearly every system we looked at (and all the systems that didn't appear to be operated by DNS nerds) published a TXT record for SPF (and maybe also published an SPF record), the SPF type lookup would just never happen. Ditching the additional lookup logic leads to a simpler specification and simpler implementations, at no apparent cost. Moreover, if everyone migrated to type SPF, (2) would be bad in the same way (1) is, only worse because of the additional complexity caused by having to examine every TXT record at an owner name prior to falling through. This led us to (3). Of course, in (3), we could either deprecate the SPF type or the use of TXT for this purpose. But the deployed base has clearly spoken: TXT is the overwhelming preference, and almost everyone who publishes an SPF record also publishes a TXT SPF record. Deprecating the TXT use would mean that the actual deployed software would never stop using 4408 as its specification, because of the massive backward compatibility problem that would arise. I am very, very unhappy about this fact, but it is a fact of the world, and I think the IETF just makes itself look ridiculous if it attempts to make the rest of the world work the way we would like. There is no question that it is architecturally lousy that we're using TXT records for this. The underscore-label convention, as much as it gives me hives, offers a way for future innovations to avoid trouncing all over the TXT record at an owner name, so I don't think SPF functions as any kind of precedent. And I, as much as anyone, am extremely keen to promote the idea that new RRTYPEs are often a good idea. But we are just not in a position to try to tell the Internet not to use TXT in this particular case, and I think we're dreaming in Technicolor if we suppose that we could. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From tale@dd.org Thu Apr 25 06:21:48 2013 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 3263F21F95EB for ; Thu, 25 Apr 2013 06:21: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 EDsL0u1Pr67M for ; Thu, 25 Apr 2013 06:21:47 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 19BB321F95E9 for ; Thu, 25 Apr 2013 06:21:40 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 79D823F464; Thu, 25 Apr 2013 09:21:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20857.11747.323954.434699@gro.dd.org> Date: Thu, 25 Apr 2013 09:21:39 -0400 From: Dave Lawrence To: dnsext@ietf.org In-Reply-To: <20130425123430.GC18348@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> <20130425123430.GC18348@mx1.yitter.info> Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 13:21:48 -0000 Andrew Sullivan writes: > 1. Specify that clients query first SPF, and then query TXT if > SPF returned NODATA. > [...] > We rejected (1) (in consultation with DNSOP) on the grounds that the > evidence showed overwhelmingly that deployed systems used TXT in > preference to SPF. A number of systems (including, full disclosure, > one of the services that my employer, Dyn, offers) to this day only > support SPF using TXT records. So, (1) would result in an increase of > query traffic with little, if any, benefit. In the near term. It is unclear what the effect would be long term. I know that, as an implementer, if I had a spec that was unambiguous about the intended behaviour of SPF-then-TXT that I would endeavour to make my software be part of the evolution that moved things in the right direction. (I currently work on a widely deployed auth server, not a resolver, and that server supports the SPF record.) I will not pretend to prognosticate, however, on whether similar action by other developers would be widespread enough to eventually noticeably mitigate the extra query hit. I don't think anyone else can convincingly make the case that they really know how it would work out, either. As an operator, both for a large organization and also one whose personal DNS server sits behind a pretty small pipe, to me that extra hit is hardly a worse situation than AAAA-then-A. From paul.hoffman@vpnc.org Thu Apr 25 06:33:24 2013 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 E194A21F961D for ; Thu, 25 Apr 2013 06:33:24 -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 TD6oIlwjom9j for ; Thu, 25 Apr 2013 06:33: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 7021821F961B for ; Thu, 25 Apr 2013 06:33:24 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3PDX9F8069700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 06:33:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Date: Thu, 25 Apr 2013 06:33:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33B808F3-C826-4EBC-8AF5-3E9CE669407B@vpnc.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) Cc: DNSEXT Working Group Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 13:33:25 -0000 On Apr 23, 2013, at 3:03 PM, S Moonesamy wrote: > Hello, >=20 > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: >=20 > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >=20 > Is the annotation in the DNS Parameters registry correct? Yes, it is correct. Isn't it amazing that the DNSEXT WG can't answer a simple question = without turning it into a lecture about How Things Would Be Done If We = Were Kings and Queens? (Actually, no one even bothered to answer the = question...) --Paul Hoffman= From ajs@anvilwalrusden.com Thu Apr 25 07:04:54 2013 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 873D521F91D9 for ; Thu, 25 Apr 2013 07:04:54 -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 0Xk28O6CKBEc for ; Thu, 25 Apr 2013 07:04:54 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1529D21F9079 for ; Thu, 25 Apr 2013 07:04:54 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5CA168A031 for ; Thu, 25 Apr 2013 14:04:53 +0000 (UTC) Date: Thu, 25 Apr 2013 10:04:51 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130425140451.GN18348@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> <20130425123430.GC18348@mx1.yitter.info> <20857.11747.323954.434699@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20857.11747.323954.434699@gro.dd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 14:04:54 -0000 On Thu, Apr 25, 2013 at 09:21:39AM -0400, Dave Lawrence wrote: > personal DNS server sits behind a pretty small pipe, to me that extra > hit is hardly a worse situation than AAAA-then-A. No hat. It was partly the never-ending complaints about that very situation that led me to believe that the extra traffic would be a bad thing. But, with my moderator hat on, if people want to argue about this, however, the correct place to do it is on the spfbis list, please. A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Thu Apr 25 07:09:00 2013 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 70AB021F943A for ; Thu, 25 Apr 2013 07:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp+W7NKTBDCU for ; Thu, 25 Apr 2013 07:09:00 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDEE21F9412 for ; Thu, 25 Apr 2013 07:08:57 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id 0740F21D88; Thu, 25 Apr 2013 16:08:55 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> Date: Thu, 25 Apr 2013 16:08:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> To: David Conrad , John R Levine X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 14:09:00 -0000 >> Once again, the huge practical barriers to deploying new RRTYPEs made = the SPF RR dead on arrival. John, I completely disagree, as you know, with this statement. What = killed SPF RR was the introduction of the TXT cludge for SPF. I therefore support David in this: > Yes, the ossification of the DNS makes introducing new things = challenging however as Mark pointed out, software was beginning to do = the right thing and there actually are web interfaces out there that let = folks enter SPF records (I use one). My reading of 6686 would suggest = that SPF has greater penetration than either DNSSEC or IPv6 which both = face the practical barriers you mention, yet I'd argue deploying DNSSEC = and IPv6 are the right thing to do. We do deploy IPv6 and DNSSEC with new RR types. Having that in TXT would = have made things not just a little bit messier. Patrik From johnl@taugh.com Thu Apr 25 07:44:55 2013 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 135B221F92BD for ; Thu, 25 Apr 2013 07:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7YaUXRAOVj8 for ; Thu, 25 Apr 2013 07:44:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8F23C21F8F28 for ; Thu, 25 Apr 2013 07:44:53 -0700 (PDT) Received: (qmail 17577 invoked from network); 25 Apr 2013 14:44:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=44a8.51794165.k1304; bh=M6GKpW4jiKw7OWBrnc9CpTS6yXpvfZkSHFwt8GbsaUo=; b=NuMPzDrzB6ziH+22xwBNnBqfE15eBGAeRgC0AT0ixTpe1ijQMUUlIOYY29tyW2//JWd0d+dua+QnGvwdXuN6JDG0u1zoCiI9eRY9ten6NZ7WA2T+WJO9iQdqlYGecDHcs3GZwJICl2qPCU/oxp6UUt+r2A0f1Dy+HZYDY27PHMY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=44a8.51794165.k1304; bh=M6GKpW4jiKw7OWBrnc9CpTS6yXpvfZkSHFwt8GbsaUo=; b=pcsMjMtRtOBFIIan4ESMD7yEcbVRcULxNQDFg6how4AFwor8Tbl71Lse72hScxLm3Y8pix13xAwyH6PR068V7ehL9c+h1thEa8RnhOH9jcnIJv1ZmFkg/B+XkudVQ+cbjEWAMGA60iLxWQNjUV9LWWZr8mFJ4Mu7VY9Tt+VF5oI= Received: (ofmipd 127.0.0.1); 25 Apr 2013 14:44:30 -0000 Date: 25 Apr 2013 10:44:52 -0400 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 14:44:55 -0000 >>> Once again, the huge practical barriers to deploying new RRTYPEs made the SPF RR dead on arrival. > > John, I completely disagree, as you know, with this statement. What > killed SPF RR was the introduction of the TXT kludge for SPF. You're confusing cause and effect. For one thing, back in 2004-2005 getting a new RR type allocated was so painful that it wasn't worth the effort when they were trying out SPF. I realize this problem has been somewhat alleviated. The much more serious reason is that the provisioning systems to let system managers install type 99 records into their DNS did not exist, and for the most part still do not exist. I know a lot of the people who did early SPF installations and they uniformly reported that even getting the provisioning software to support TXT records that have been around since the dawn of the DNS was painful, and there would have been no hope for a new and exotic record type. Since their goal was to make SPF actually work, they used a kludge. It's the same reason DKIM uses TXT records. >> Yes, the ossification of the DNS makes introducing new things >> challenging however as Mark pointed out, software was beginning to do >> the right thing and there actually are web interfaces out there that >> let folks enter SPF records (I use one). Wow, and it's only taken eight fripping years. Perhaps if we wait another century the provisioning systems will catch up. If the DNS crowd spent half the effort addressing the provisioning problem that you do trying to deny that it exists, it'd have been fixed years ago. My dnsextlang proposal is one approach, but surely not the only one. In any event, the SPF draft is in WGLC. Feel free to read the extensive discussion in the list archives and let them know how you feel. R's, John PS: The system that lets you enter SPF records wouldn't be Godaddy, would it? If so, create an SPF record, then do a dig and try to find it. From paf@frobbit.se Thu Apr 25 08:03:57 2013 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 0D82E21F9590 for ; Thu, 25 Apr 2013 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssfG+BMHUzFT for ; Thu, 25 Apr 2013 08:03:56 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDA21F95F0 for ; Thu, 25 Apr 2013 08:03:56 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id A9D2E21D79; Thu, 25 Apr 2013 17:03:55 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 25 Apr 2013 17:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> To: John R Levine X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:03:57 -0000 On 25 apr 2013, at 16:44, John R Levine wrote: > In any event, the SPF draft is in WGLC. Feel free to read the = extensive discussion in the list archives and let them know how you = feel. They know how i feel. We in IETF do believe in rough consensus. I am = this time on the rough side. That does not imply I am quiet in other places, and I am as many others = nervous over the implications. Patrik From johnl@taugh.com Thu Apr 25 08:05:16 2013 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 9BC5B21F8EBB for ; Thu, 25 Apr 2013 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cZgzHD4MaU1 for ; Thu, 25 Apr 2013 08:05:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 083BF21F9610 for ; Thu, 25 Apr 2013 08:05:14 -0700 (PDT) Received: (qmail 22286 invoked from network); 25 Apr 2013 15:05:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=570b.51794628.k1304; bh=tMWm+SZZh2+FGqA8q7OLN9d2HvKMuboabngJFaKgkHM=; b=ecF8nC5csGs3zQXVaiWR1yZcA5Q9rLCCjuODf8YxCC8Kgc7pDLT+h5pTS1ZTexct2WnEsov6fDbzCXpFDdFnAqkY7SyCIr8/4i+74AuB/WIM9duvT/HRUWCKxyhmFmFq7vWu/Kjy1TKHY+xJN7gUkJKhDGiHn59iBWopMzs+ehM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=570b.51794628.k1304; bh=tMWm+SZZh2+FGqA8q7OLN9d2HvKMuboabngJFaKgkHM=; b=y9yZQzTjAldXiaFUjm+87bH75yqsZbeQA3VS2MJbbIIMA4PTG6ymOi8opu9btDrCnX7WbTLNwtVh5Vip1YbNg4mGpuBHK9smQu03yTiAxhdeS7OKLjSFAoTZzs56eCHRNi0BWSn6E0U+l0uPYGv4NBYexqvB3a0qjfZ6dfkAsQU= Received: (ofmipd 127.0.0.1); 25 Apr 2013 15:04:50 -0000 Date: 25 Apr 2013 11:05:12 -0400 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" In-Reply-To: <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:05:16 -0000 > That does not imply I am quiet in other places, and I am as many others nervous over the implications. That we have a large and unaddressed problem of cruddy provisioning software? I entirely agree. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From mansaxel@besserwisser.org Thu Apr 25 08:42:37 2013 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 C1F7021F9605; Thu, 25 Apr 2013 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB5DlEYBdBCR; Thu, 25 Apr 2013 08:42:37 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 38BA121F9604; Thu, 25 Apr 2013 08:42:36 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 6522A9EF0; Thu, 25 Apr 2013 17:42:35 +0200 (CEST) Date: Thu, 25 Apr 2013 17:42:35 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= Message-ID: <20130425154235.GP23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftQmbtOmUf2cr8rB" Content-Disposition: inline In-Reply-To: <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:42:37 -0000 --ftQmbtOmUf2cr8rB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at 05:0= 3:55PM +0200 Quoting Patrik F=C3=A4ltstr=C3=B6m (paf@frobbit.se): >=20 > On 25 apr 2013, at 16:44, John R Levine wrote: >=20 > > In any event, the SPF draft is in WGLC. Feel free to read the extensiv= e discussion in the list archives and let them know how you feel. >=20 > They know how i feel. We in IETF do believe in rough consensus. I am this= time on the rough side. >=20 > That does not imply I am quiet in other places, and I am as many others n= ervous over the implications. This is a slippery slope. One record overload is not bad, but it sort of opens the floodgates for systematic overloading. DNSEXT and DNSOP certainly need to get involved; because this is way bigger than just SPF. And IMNSHO spfbis is out of scope prescribing TXT records, just because of this contagiousness. For the record: I think that the spfbis draft is unfit for publication as RFC unless TXT records are deprectaed as only carrier of data. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 =2E.. I want FORTY-TWO TRYNEL FLOATATION SYSTEMS installed within SIX AND A HALF HOURS!!! --ftQmbtOmUf2cr8rB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF5TusACgkQ02/pMZDM1cUQggCfaxOyZqwStzExMXJIhjfUpum8 u08AnRH+iYj934pT7mmbD1y2g/IV6ZzF =tXWw -----END PGP SIGNATURE----- --ftQmbtOmUf2cr8rB-- From Ted.Lemon@nominum.com Thu Apr 25 09:01:55 2013 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 4013B21F9650 for ; Thu, 25 Apr 2013 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.352 X-Spam-Level: X-Spam-Status: No, score=-106.352 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 0LAZlWWhm2hs for ; Thu, 25 Apr 2013 09:01:54 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id D019A21F9642 for ; Thu, 25 Apr 2013 09:01:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUXlTcB0QsoNiq3eeR6VN4yK4EDNVHGu9@postini.com; Thu, 25 Apr 2013 09:01:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4B3471B80DF for ; Thu, 25 Apr 2013 09:01:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 42442190052; Thu, 25 Apr 2013 09:01:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 09:01:52 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQUvZmmQ2JXTkhEy3ea4oJfG13ZjmnHmAgAAREQCAAMIRgIAACgkAgAAFUoCAABAwgA== Date: Thu, 25 Apr 2013 16:01:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> In-Reply-To: <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F0094F7AB7F9D4CBE5B267CC9A73D83@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:01:55 -0000 On Apr 25, 2013, at 11:03 AM, Patrik F=E4ltstr=F6m wrote: > They know how i feel. We in IETF do believe in rough consensus. I am this= time on the rough side. It seems to be the case that there are rather a lot of people on the dnsext= mailing list who are on the rough side of the consensus here. That sugge= sts that perhaps the consensus isn't in the direction that we are presuming= it is. From johnl@iecc.com Thu Apr 25 09:16:54 2013 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 C8D1621F868B for ; Thu, 25 Apr 2013 09:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 q0nj5zkzxs97 for ; Thu, 25 Apr 2013 09:16:54 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CA91F21F85E8 for ; Thu, 25 Apr 2013 09:16:53 -0700 (PDT) Received: (qmail 35526 invoked from network); 25 Apr 2013 16:16:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2013 16:16:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517956f4.xn--9vv.k1304; i=johnl@user.iecc.com; bh=+8M2mAaEb4doA6bPpbtRC1qRcPXT9ZW5pK6rR1z73NY=; b=BfS431xNEJRbzD0ILsmHVIlGmvmX9WE1mMZ2KcI2dkQNjKXckLu4LlbWXtvndo/PtY2nYS+KapEe+qhyPTmDxL6dOrvR0r0gk20Z6Y9oxZVR4eREHFhx3skfq7IX7Oibkw7sDy8sWCjlqZlSoyqx2Hw+ubKozFXZng7RhI4gn8w= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517956f4.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=+8M2mAaEb4doA6bPpbtRC1qRcPXT9ZW5pK6rR1z73NY=; b=PZlo2IARgc3SvO7SyZO6mbiARARg3Z4s7YKPdyQ5+ZVL4skOdM540mfV0y+Q21OcJzgsIFfgTZbjPZp7tbC3eZzrtUXmXnSc6d4V2O5XWpo0mf9FPeNRFyFiGpNOEEb1FyBIqy6rf+F7AmsAoUieM7Qp36D9hbfdUdJxfAIb3OY= Date: 25 Apr 2013 16:16:30 -0000 Message-ID: <20130425161630.65751.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:16:55 -0000 >In the near term. It is unclear what the effect would be long term. There are at least several hundred thousand mail systems publishing TXT SPF records, and presumably a similar number checking them. Their SPF deployment works fine. It is absurd to claim that TXT SPF records will ever stop working. Why should they change? What's the justification for spending money on software that provides them no benefits? I published type 99 records for a while and can report from direct experience that they did, indeed, provide no benefit whatsoever, and a certain amount of hassle due to other systems whose type 99 code turned out to be buggy. R's, John PS: Nobody's arguing that SPF is a well designed protocol, but its installed base is undeniable. From paul.hoffman@vpnc.org Thu Apr 25 09:21:54 2013 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 B539321F960F for ; Thu, 25 Apr 2013 09:21:53 -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.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 8883QMkGmAJu for ; Thu, 25 Apr 2013 09:21:51 -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 2C68C21F9606 for ; Thu, 25 Apr 2013 09:21:49 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3PGLg31075703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 09:21:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> Date: Thu, 25 Apr 2013 09:21:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F22F597-1FD0-4A79-BC18-C66E7FB4EFEE@vpnc.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:21:54 -0000 On Apr 25, 2013, at 9:01 AM, Ted Lemon wrote: > On Apr 25, 2013, at 11:03 AM, Patrik F=E4ltstr=F6m = wrote: >> They know how i feel. We in IETF do believe in rough consensus. I am = this time on the rough side. >=20 > It seems to be the case that there are rather a lot of people on the = dnsext mailing list who are on the rough side of the consensus here. = That suggests that perhaps the consensus isn't in the direction that we = are presuming it is. Are you saying that the people on the DNSEXT mailing list read the = document that is in WG LC in the other WG? If so, please re-read the = comments above. It is pretty clear most did not. Helping form consensus = means more than voicing an uninformed reaction on an unrelated mailing = list: it takes work and concern for everybody else who is doing work. --Paul Hoffman= From jim@rfc1035.com Thu Apr 25 09:27:28 2013 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 EB5F121F8D71 for ; Thu, 25 Apr 2013 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QsAT-stqes7Y for ; Thu, 25 Apr 2013 09:27:27 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 312D521F9615 for ; Thu, 25 Apr 2013 09:26:41 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id AC910CBC41F; Thu, 25 Apr 2013 17:26:37 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <51791EFC.5060907@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Apr 2013 17:26:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58A063F4-E0E3-4C45-AA56-93AF79A3E2FD@rfc1035.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <20130425095856.GA18148@mx1.yitter.info> <51791EFC.5060907@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:27:29 -0000 On 25 Apr 2013, at 13:18, Masataka Ohta = wrote: > Andrew Sullivan wrote: >=20 >> One obvious one is, "Don't have two mechanisms to achieve the same = goal." >=20 > It means anything to be implemented by TXT can not have its own RR. If anything it means the opposite: please don't use a TXT record when a = unique RRtype could be used instead. Or at the very mininum it means = choose between one or the other, not both. >> Given that SPF has the TXT record and that there is zero hope >> of getting rid of that use, the SPF RRTYPE was just a vain hope. >=20 > "there is zero hope of getting rid of that use"? Why? Once stuff has been deployed, there's almost no chance of un-deploying = it. If you think all the mail software using SPF will switch from TXT = records to SPF records (or vice versa), feel free to document how to = make that happen. > Where is the advice not to have underscore-label extensions with SRV? I think you've misunderstood. Of course there's no such advice. [SRV = records explicitly use underscores in certain labels so their domain = names avoid clashing with host names (which can't contain underscores). = An SRV record of sip.udp.example.com would be bad if there already was = an A or MX record (say) for that hostname.] Others have adopted this = practice/convention: some SPF users it seems. RFC5507 discusses the sort = of things to consider when planning to add suffixes or prefixes to = domain names. > The problem of underscore-label extensions is that the > underscore-labels is not assured to be unique (RFC1034 > imposes no restriction to use underscore-label for any > purpose) and can have conflicts to other applications. All domain names are by definition unique. Whether they contain = underscores or not. Anyone inserting an underscore somewhere in an = existing domain name creates a new domain name that might already exist. = So what?= From warren@kumari.net Thu Apr 25 09:31:14 2013 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 5531021F9457 for ; Thu, 25 Apr 2013 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.189, 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 DfPIRcD8KPfV for ; Thu, 25 Apr 2013 09:31:13 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38FD21F9361 for ; Thu, 25 Apr 2013 09:31:13 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 2CA351B40244; Thu, 25 Apr 2013 12:31:12 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <20130425154235.GP23770@besserwisser.org> Date: Thu, 25 Apr 2013 12:31:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7292D45C-1522-44DB-B6E3-3FCB313D5D16@kumari.net> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> To: =?iso-8859-1?Q?M=E5ns_Nilsson?= X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:31:14 -0000 [-spfbis, because this bit is just DNS ]=20 On Apr 25, 2013, at 11:42 AM, M=E5ns Nilsson = wrote: > Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at = 05:03:55PM +0200 Quoting Patrik F=E4ltstr=F6m (paf@frobbit.se): >>=20 >> On 25 apr 2013, at 16:44, John R Levine wrote: >>=20 >>> In any event, the SPF draft is in WGLC. Feel free to read the = extensive discussion in the list archives and let them know how you = feel. >>=20 >> They know how i feel. We in IETF do believe in rough consensus. I am = this time on the rough side. >>=20 >> That does not imply I am quiet in other places, and I am as many = others nervous over the implications. >=20 > This is a slippery slope. One record overload is not bad, but it sort > of opens the floodgates for systematic overloading. DNSEXT and DNSOP > certainly need to get involved; because this is way bigger than just = SPF. There were a set of (protracted) discussions in DANE on having our own = RR type or overloading TXT. There were a number of arguments on each side, but much of it boiled = down to: a: web based provisioning systems suck, and some middle boxes dinkle = with unknown RR types, so use TXT. b: overloading TXT is inelegant and required custom and complex parsers. = Also, some of the data we want to carry is binary, and so you'd have to = b64 (or something) encode it (not insurmountable, but annoying). As always there were fairly strong views (and each side had folk who = were, or believed that they were, DNS experts), but the consensus ended = up being a dedicated RR type. As an aside, the RR type allocation process was painless and quick. An easily accessible document describing the implications of choosing an = RR type over funky TXT records, and how to evaluate these would be = useful. Added brownie points if the document also describes how to do discovery = / naming. TLSA settled on the _port._protcol.host.example.com = "standard", but much time was spent on this discussion (and if = tree-walking could be performed, and if so how, etc.) Yes, everyone's needs are different, but being able say "Some DNS wonks = have already thought about this, go read RFC $foo before commenting = please" would have been nice. W >=20 > And IMNSHO spfbis is out of scope prescribing TXT records, just = because > of this contagiousness. >=20 > For the record: I think that the spfbis draft is unfit for publication > as RFC unless TXT records are deprectaed as only carrier of data. > --=20 > M=E5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > ... I want FORTY-TWO TRYNEL FLOATATION SYSTEMS installed within > SIX AND A HALF HOURS!!! > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From sm@elandsys.com Wed Apr 24 21:55:51 2013 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 1F7CD21F896D; Wed, 24 Apr 2013 21:55:51 -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 y+UE8T37YJX7; Wed, 24 Apr 2013 21:55:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C121F85C0; Wed, 24 Apr 2013 21:55:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P4tWwq012233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 21:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366865745; bh=RIprv/oba+fo7x9pAwFihLodS/ddKWVZvYxlwMUB5oc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hxTdrvFuUWfAN18ZLtrg3ww1B3vFbN59zSE0m3yY8SjLxRH57SzC7zWbfQGpGd7Mc HCNx88PDaXgQsUK5avnnHVacMq2+MBr4WCu10DaaDHHKvUcK4l4hNBFc9xIC3wjAbQ EXHzc3Xus95tkqfaQlfSPN1tx1C8+L6KL8edyi1I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366865745; i=@elandsys.com; bh=RIprv/oba+fo7x9pAwFihLodS/ddKWVZvYxlwMUB5oc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0y7oMyJQD/XSR0ZYCx0HZ64H4NfG1IUBxWAmSO0URfJImCF+zpEUuTMqki6CpWPbj i6LEQ1j/MEyN/AyAoYCGwG78OLsOqd0TKVmYP2bAsz/Fo9mxwDKPfw6RP+y1Hzr1fs bMti2J4hb7+HZu3LPjIW08QDsy4BEvhRd+HXKl4s= Message-Id: <6.2.5.6.2.20130424211648.0a804468@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 21:42:03 -0700 To: David Conrad From: S Moonesamy In-Reply-To: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 25 Apr 2013 09:42:29 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 04:55:51 -0000 Hi David, At 17:12 24-04-2013, David Conrad wrote: >It is in keeping with past practice, e.g., see the notations for MD, >MF, A6, and the MAILA RRtypes at >http://www.iana.org/assignments/dns-parameters/dns-parameters.xml. Based on the current discussion a similar approach may be followed for the SPF RRTYPE. Please note that this is in my view a IANA Considerations (administrative) issue. >I personally believe deprecating the SPF RR is the wrong way to go, >but I'm guessing that discussion has already been had. Yes, the thread is at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html The results of the discussion is documented in RFC 6686. Regards, S. Moonesamy From dotzero@gmail.com Thu Apr 25 09:27:36 2013 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 472B121F8613; Thu, 25 Apr 2013 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oywa45NQFH0J; Thu, 25 Apr 2013 09:27:30 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6192021F9633; Thu, 25 Apr 2013 09:26:59 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id es20so2803456lab.27 for ; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=g+VuFvXnjcjIFs6AMfbNW3UVe3fJaK2YkdVS4rx7nrs=; b=dMA/hlwcHFjo8llVOQJxidhmySvMl907juEEu9NwFXbrhXhMznCacKy07bNg7PmSFG bAj2B4KVDSDpwrWd3okkbmyvZtI/JVtBmjJ4CBT4O0MSmwAPsl272lvsbI0ffR6daLUo OiffQpXTrOOCt0+SIpHBQWEjq+NszX7dFKeh44w9SJIIz7VLPIfcTri5p8IbiXP6ZcBr 0+20xmyePFVU9s8IgBbMNObk1EvBB2pTMHVpdumGw0SjT202dFHxPLTGmYp+b3Wd//QS 2bjKkHF2VIhUuMQbWSvroQGl6soweIsJnUMhmxFabE2LB9zP7H7GWKYu1c12sTwqKo4R RyIA== MIME-Version: 1.0 X-Received: by 10.112.135.133 with SMTP id ps5mr6641222lbb.42.1366907211779; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) In-Reply-To: <20130425154235.GP23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> Date: Thu, 25 Apr 2013 12:26:51 -0400 Message-ID: From: Dotzero To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 25 Apr 2013 09:42:31 -0700 Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:27:48 -0000 On Thu, Apr 25, 2013 at 11:42 AM, M=E5ns Nilsson wrote: > Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at 05= :03:55PM +0200 Quoting Patrik F=E4ltstr=F6m (paf@frobbit.se): >> >> On 25 apr 2013, at 16:44, John R Levine wrote: >> >> > In any event, the SPF draft is in WGLC. Feel free to read the extensi= ve discussion in the list archives and let them know how you feel. >> >> They know how i feel. We in IETF do believe in rough consensus. I am thi= s time on the rough side. >> >> That does not imply I am quiet in other places, and I am as many others = nervous over the implications. > > This is a slippery slope. One record overload is not bad, but it sort > of opens the floodgates for systematic overloading. DNSEXT and DNSOP > certainly need to get involved; because this is way bigger than just SPF. > > And IMNSHO spfbis is out of scope prescribing TXT records, just because > of this contagiousness. > It is not so much that SPFbis is prescribing practice as it is updating to describe practice and avoid potential problems that have been identified with having both TXT and type 99 records (without a lot of verbage to address hypothetical future use). > For the record: I think that the spfbis draft is unfit for publication > as RFC unless TXT records are deprectaed as only carrier of data. > Would you be any happier if the WG left type 99 records and in a coy manner made it clear that usage is overwhelmingly TXT based with little likelyhood of type 99 gathering any meaningful traction? I'm sure that if the issues surrounding adoption of new RR types were resolved we would not be having this discussion - but they haven't been resolved. Mike From jabley@hopcount.ca Thu Apr 25 09:52:29 2013 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 518A221F9682 for ; Thu, 25 Apr 2013 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 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 XjvwI8fSuiKs for ; Thu, 25 Apr 2013 09:52:28 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D204021F967F for ; Thu, 25 Apr 2013 09:52:27 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id w33so558888iag.27 for ; Thu, 25 Apr 2013 09:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=xc9tw57s0xbv5EE8KUNzPYsmcKMrsq/SH4ckZz1LciU=; b=biKinbUHjP68ucywEd82gSdSqTmAkO6QbNL981pgHfUJMRUgrmvGABcX9u+xwAtJf6 tp5B4tx42pYA6y5MpPMrKobGu++YbRLtSH3WTBS71jh/hQrEUgqSemBNmQNC07zyUBHQ pESDf0AdZi5LE6RAb7mrvjb7NQj+xsU4n44dM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xc9tw57s0xbv5EE8KUNzPYsmcKMrsq/SH4ckZz1LciU=; b=lgtKoYcxbSh/j9YA/E5DZboPnqEQd2P3Bme4DXZhGlGygXjl89IeewKbgMbVmQe2Jy 5xQJVyEwXya9YLoeREU4jgglZCUT6nxv1x6CS68ia7taTig8Qz9CcQOChhNY1gXvLEK1 oBBEOx+hyOFNAe6MeCTDu/ckoUlJxaoc2hjWtQOIZD66C91K35TsSbSkdhfvMP8A1b1A FizdTkvILQcb3bwKbPh/tgFzZk5RHnkK+lIfM4SA3F+9smxaddm95ZOOuvsABrKqe4am bB7gZ7KoOsO/u6AVB24gq+VZap/jlPoC92yYQZzlBN0O4p+LC3516FbHgf5kVMAA35sN cHYg== X-Received: by 10.50.45.230 with SMTP id q6mr19292032igm.39.1366908747374; Thu, 25 Apr 2013 09:52:27 -0700 (PDT) Received: from [10.105.67.31] ([75.98.19.132]) by mx.google.com with ESMTPSA id hi4sm13639975igc.6.2013.04.25.09.52.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 09:52:26 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <7292D45C-1522-44DB-B6E3-3FCB313D5D16@kumari.net> Date: Thu, 25 Apr 2013 12:52:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7DDAE47B-6962-48C3-908F-D7A6DE1B7029@hopcount.ca> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <7292D45C-1522-44DB-B6E3-3FCB313D5D16@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlEt3XfM/SMf+tvmQlo3z53858cTDSsWgSrIP9kU7nsLODC6SN3rVK9KC5dOwHH47J53U+h Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:52:29 -0000 On 2013-04-25, at 12:31, Warren Kumari wrote: > An easily accessible document describing the implications of choosing = an RR type over funky TXT records, and how to evaluate these would be = useful. http://tools.ietf.org/html/rfc5507#section-5 > Added brownie points if the document also describes how to do = discovery / naming. http://tools.ietf.org/html/rfc5507#section-3.2 > TLSA settled on the _port._protcol.host.example.com "standard", but = much time was spent on this discussion (and if tree-walking could be = performed, and if so how, etc.) > Yes, everyone's needs are different, but being able say "Some DNS = wonks have already thought about this, go read RFC $foo before = commenting please" would have been nice. http://tools.ietf.org/html/rfc5507 Joe From jabley@hopcount.ca Thu Apr 25 09:54:39 2013 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 1F9DC21F925B for ; Thu, 25 Apr 2013 09:54: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 0Kw+FyNMrb3h for ; Thu, 25 Apr 2013 09:54:38 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7167521F8B07 for ; Thu, 25 Apr 2013 09:54:28 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id aq17so3968747iec.9 for ; Thu, 25 Apr 2013 09:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=36j/KS3McVEurT5t24Y3uaS7R4e4lHRWFyfbGSDaLuU=; b=A/jFkbh4QrHYE6pkaFswI62sWH4bEc4dC+Gv1Me6XDHql/u4hkwYL7sD4kNChfa0Cb SXcbpODOSqyVD5bh2u4tb0UOFAmZ7LflCo/PxmIZJZxxjZ4jseBNdaNLi+BjX2vgT5kO PKhM50XJtFwlpmzQpYzZdecEtryXVSMslylkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=36j/KS3McVEurT5t24Y3uaS7R4e4lHRWFyfbGSDaLuU=; b=VTiE2wOOW/WEyK5x/4zCI3ZiQ3NXiEqyymGNY6BGhlSQpYVPXNO53RFqSDpG6rLmnC BijgWRy3UeVV2WO9m4n3G1QBjnaM6AMvci76sZKV7Ief4lJ+W5xTWAPgYrHOC4lhPWk/ g4zvdcjZnd7/dVhSsw+WTyi9gZg9o2UG2zYExFGPHY+lGYQ2Hr2kkxvsAZn3FgKqeF8g GY5d70+5ig4EQEctI6OVifiNe1wgJd5QVaInCp5DRrvhq2ohiEz6/qlezexhiymbEcA7 t0RA1uxbPNOq6kcqobrGRukd5q48Fs5zhOJCj69tfpGi7XptwyUad6zcyVYE79NYp9+n HQ0g== X-Received: by 10.50.62.66 with SMTP id w2mr18136168igr.81.1366908866262; Thu, 25 Apr 2013 09:54:26 -0700 (PDT) Received: from [10.105.67.31] ([75.98.19.132]) by mx.google.com with ESMTPSA id hi4sm13649348igc.6.2013.04.25.09.54.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 09:54:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Thu, 25 Apr 2013 12:54:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> To: John R Levine X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmnZuc5e8D9Ys2nyTUr86ANv597v3aXyzmUCa9AM3wCY115FJ3n1sc6KmNktIbop7+GHNnq Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:54:39 -0000 On 2013-04-25, at 10:44, John R Levine wrote: > The much more serious reason is that the provisioning systems to let = system managers install type 99 records into their DNS did not exist, = and for the most part still do not exist. I know a lot of the people = who did early SPF installations and they uniformly reported that even = getting the provisioning software to support TXT records that have been = around since the dawn of the DNS was painful, and there would have been = no hope for a new and exotic record type. Wait; support for the SPF RRType would have involved changes in = provisioning systems, so instead the decision was to use TXT RRTypes = which involved changes in provisioning systems? Awesome. :-) Joe= From dougb@dougbarton.us Thu Apr 25 09:58:57 2013 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 6073421F96AB for ; Thu, 25 Apr 2013 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UjgDvhwM9YXj for ; Thu, 25 Apr 2013 09:58:56 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id A8EA121F8E46 for ; Thu, 25 Apr 2013 09:58:56 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:dce0:a142:9806:1a87] (unknown [IPv6:2001:470:d:5e7:dce0:a142:9806:1a87]) by dougbarton.us (Postfix) with ESMTPSA id 4DF9D22BA8 for ; Thu, 25 Apr 2013 16:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366909135; bh=koCwuiy8PT4IgOQliSM0TqsLfeJSED1EssR5q7A+Dio=; h=Date:From:To:Subject:References:In-Reply-To; b=jDjHjr+0PwZ1KiXh55coEDOivUHkQs7V/cH8HnvWxOt6Ad6zwpmkOL2qUUjB8J2W0 SCkWMDc/uJ+28cH7P8+XLOk/SKbhhetL6wc7H3lgn9uGof6sSsnWr3skS8vJBh2X9E pP7hlcRvP2DrS/xXvkYtTKAOkRQowcdkp95rSztE= Message-ID: <517960CE.70604@dougbarton.us> Date: Thu, 25 Apr 2013 09:58:54 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> <20130425075147.GN23770@besserwisser.org> In-Reply-To: <20130425075147.GN23770@besserwisser.org> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:58:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/25/2013 12:51 AM, Måns Nilsson wrote: | | OTOH, mixing up routing layer with application layer and gilding some | IP addresses in favour of others is another Really Bad Idea; I'd rather | throw the entire business of supposedly Good and Bad addresses out the | window and start looking at the in-band data instead; ie. DKIM or similar. Måns, SPF has one important benefit that DKIM cannot, reduction of joe-jobbing. I used to get backscatter at the rate of at least 2-3 per day, with peaks of 10-20. After adding an SPF record with the hard-fail option that's down to a couple per month. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBCAAGBQJReWDOAAoJEFzGhvEaGryEP9MH/0rgYgNClSehCLrR35PW8qo6 j+bppCf4gkGrZ9rtmWLQx+m1EMNlm+w+6eZDpvOSeMofyk9/7ri0ns+e28qjSl+c lM+wgjl4+jrgmFc4LCp3I9cH1/2P1v5bca3Bzp1JDg9iMXz0S7bapzafaTamktvS Z+LhYWV4WXPmUju2J/uAUEDozLZpvKlZMDVprbVeoDJLTIJFt8zOpQCEI6E/nK+v itSEjiF+znxVnr39lyuJeExD+1l+0qb624BaixGb9/ytvAWTG2vnqCcgGhv0YqfZ m3b6SgZFySkG9+Wt2R5dHKm/g3jt69k/Jj7WmIgwgVwCAXZOne/5hVZS7pLJzOo= =QJ1r -----END PGP SIGNATURE----- From warren@kumari.net Thu Apr 25 10:08:12 2013 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 DED6921F96B6 for ; Thu, 25 Apr 2013 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 dDfTMB5wc8yK for ; Thu, 25 Apr 2013 10:08:12 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374721F96B4 for ; Thu, 25 Apr 2013 10:08:12 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 66F851B405F4; Thu, 25 Apr 2013 13:08:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <7DDAE47B-6962-48C3-908F-D7A6DE1B7029@hopcount.ca> Date: Thu, 25 Apr 2013 13:08:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <7292D45C-1522-44DB-B6E3-3FCB313D5D16@kumari.net> <7DDAE47B-6962-48C3-908F-D7A6DE1B7029@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:08:13 -0000 On Apr 25, 2013, at 12:52 PM, Joe Abley wrote: >=20 > On 2013-04-25, at 12:31, Warren Kumari wrote: >=20 >> An easily accessible document describing the implications of choosing = an RR type over funky TXT records, and how to evaluate these would be = useful. >=20 > http://tools.ietf.org/html/rfc5507#section-5 Doh. >=20 >> Added brownie points if the document also describes how to do = discovery / naming. >=20 > http://tools.ietf.org/html/rfc5507#section-3.2 Doh, doh. >=20 >> TLSA settled on the _port._protcol.host.example.com "standard", but = much time was spent on this discussion (and if tree-walking could be = performed, and if so how, etc.) >> Yes, everyone's needs are different, but being able say "Some DNS = wonks have already thought about this, go read RFC $foo before = commenting please" would have been nice. >=20 > http://tools.ietf.org/html/rfc5507 Yup, you are right -- I forgotten this document=85 Well, actually I = hadn't forgotten it, I just remembered it as being more "Please don't = just stuff random crap in the DNS", then some motherhood and apple-pie = stuff. Maybe I'm confusing it with something else? Whatever the case, = oops. Oh, someone also pointed out (off-list) that my message sounded like I = was saying SPFbis is doing the wrong thing here. That was not my intent = (I personally think that TXT is less elegant than a dedicated record, = but a: they *appear* to have throughout this through, b: I have only = skimmed their documents, but there are chats and graphs, and c: I have = not been following the WG) -- my intent was instead to say that a = document like, er, rfc5507 would be useful :-P Blushes and wanders off-stage, W >=20 >=20 > Joe >=20 -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett From presnick@qti.qualcomm.com Thu Apr 25 10:34:28 2013 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 35B6521F881C; Thu, 25 Apr 2013 10:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.006, 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 CjG0ob3fpVOH; Thu, 25 Apr 2013 10:34:27 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF07121F84B7; Thu, 25 Apr 2013 10:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366911263; x=1398447263; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UUj3Q3VaadkoiSop6s1H9kEW06YTCTIgMEyBMHqTIjE=; b=r9E2V+qST9RvAduSI3DVAFO25+L9s47EwftX0U6MHCs5RAmMa9Az99Fd 0qqBdLuFq0bCbG6QDBUGUS5vft0HxjlMFFXcxykRfZHKXp0QviqE8fH3Y 6pJ5ZlpcIr6+2uCB8i9Mi/FD8Te9q4X+8PBK9QomR3dSCViE9SCLdTSDm E=; X-IronPort-AV: E=Sophos;i="4.87,551,1363158000"; d="scan'208";a="36633237" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 25 Apr 2013 10:34:21 -0700 X-IronPort-AV: E=Sophos;i="4.87,551,1363158000"; d="scan'208";a="438587763" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 10:34:21 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 10:34:21 -0700 Message-ID: <5179691B.50602@qti.qualcomm.com> Date: Thu, 25 Apr 2013 12:34:19 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> In-Reply-To: <20130425154235.GP23770@besserwisser.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:34:28 -0000 On 4/25/13 10:42 AM, Måns Nilsson wrote: > And IMNSHO spfbis is out of scope prescribing TXT records, just because > of this contagiousness. > > For the record: I think that the spfbis draft is unfit for publication > as RFC unless TXT records are deprectaed as only carrier of data. > SPFBIS AD hat on for this: We are *long* past this discussion. This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter. I certainly have the same heartburn as everyone else about having used TXT in this manner, but that ship has long sailed. This is running and interoperable code and it is being documented on the standards track. Unless you think there is a piece of information I missed in my assessment that we had consensus to go forward with this work in the first place, you are going to have a hard time convincing me that this is not in the rough part of the consensus now. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From johnl@taugh.com Thu Apr 25 10:59:06 2013 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 6BD4421F96A2 for ; Thu, 25 Apr 2013 10:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 D2AlSAl-4F9X for ; Thu, 25 Apr 2013 10:59:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5C221F969E for ; Thu, 25 Apr 2013 10:59:05 -0700 (PDT) Received: (qmail 19173 invoked from network); 25 Apr 2013 17:59:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=4ae4.51796ee9.k1304; bh=+TjhHTxL0VF2KdO52QBLLrwZ/aH02C0kJRJMxbv3iOw=; b=JHON1CWBV5JPj/i9lQSPor8Cgq1qWq450aevXoMUAItZMIpPYtTFE1BTqBB8gocsZsmVBI8afmCoFC4OEfZtvukeibpRZKI5QctiP1VLnieVK0hm9pb8rtE8BmgSlo913PzgEDGEkSEbWqbhLFeKvfCQi+BE0CNylCSh/wuYAt0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=4ae4.51796ee9.k1304; bh=+TjhHTxL0VF2KdO52QBLLrwZ/aH02C0kJRJMxbv3iOw=; b=g3lHIpC/9/7O5Bzv+UftNUVmNAab6Iyagr49icOLqK59VxuebZkQRVncXqP2FbobZk+a+cD5ej+mmEjQ7jObH/fqGFhCpBC35qbMQKkNeIwftBOgBRk9PM6UK/gy3Na0CVr4yjy7qb0A+jc4KXEfdv+ORu6/9lIFaBM7vXIyzdU= Received: (ofmipd 127.0.0.1); 25 Apr 2013 17:58:43 -0000 Date: 25 Apr 2013 13:59:04 -0400 Message-ID: From: "John R Levine" To: "Joe Abley" In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:59:06 -0000 > Wait; support for the SPF RRType would have involved changes in provisioning systems, so instead the decision was to use TXT RRTypes which involved changes in provisioning systems? > > Awesome. :-) Sheesh. The changes were a lot less, and were a lot easier to explain since everyone with even the most cursory familiarity with DNS knows what TXT records are. Meow, John From warren@kumari.net Thu Apr 25 11:03:08 2013 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 0383421F96AB; Thu, 25 Apr 2013 11:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 PXRRTeXtAH8D; Thu, 25 Apr 2013 11:03:07 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CA321F96B1; Thu, 25 Apr 2013 11:03:07 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id D885F1B400BD; Thu, 25 Apr 2013 14:03:06 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <5179691B.50602@qti.qualcomm.com> Date: Thu, 25 Apr 2013 14:03:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:03:08 -0000 On Apr 25, 2013, at 1:34 PM, Pete Resnick = wrote: > On 4/25/13 10:42 AM, M=E5ns Nilsson wrote: >> And IMNSHO spfbis is out of scope prescribing TXT records, just = because >> of this contagiousness. >>=20 >> For the record: I think that the spfbis draft is unfit for = publication >> as RFC unless TXT records are deprectaed as only carrier of data. >> =20 >=20 > SPFBIS AD hat on for this: >=20 > We are *long* past this discussion. This discussion should have = happened at SPFBIS *chartering* time, as it is crystal clear from the = charter that existing features currently in use in SPF are not going = away. Indeed, the TXT record was specifically mentioned in the charter. >=20 > I certainly have the same heartburn as everyone else about having used = TXT in this manner, but that ship has long sailed. This is running and = interoperable code and it is being documented on the standards track. = Unless you think there is a piece of information I missed in my = assessment that we had consensus to go forward with this work in the = first place, you are going to have a hard time convincing me that this = is not in the rough part of the consensus now. I would also recommend that folk actually go and read RFC6686 [0] - I = know that having actual measurements interferes with one's ability to = have a fun little rant, but, if you do, maybe you can avoid looking = silly (like I did with the RFC5507 discussion :-)). Maybe stuffing stuff in a TXT record was a poor decision. Maybe it = wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't = change that, and I'm sure we can find something else more fun to kvetch = about... W [0]: Yes, I know finding the documents can be hard. Here is a link: = http://tools.ietf.org/html/rfc6686 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From warren@kumari.net Thu Apr 25 11:16:20 2013 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 91F3721F9642; Thu, 25 Apr 2013 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 93XLqTskaQbR; Thu, 25 Apr 2013 11:16:19 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B25821F9692; Thu, 25 Apr 2013 11:16:18 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 7DA0F1B405F4; Thu, 25 Apr 2013 14:16:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> Date: Thu, 25 Apr 2013 14:16:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83A5592A-44F5-40AD-BA2C-05A5F0EBD100@kumari.net> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> To: Pete Resnick X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:16:20 -0000 [ Whee, replying to my own message. Always a good sign=85]=20 On Apr 25, 2013, at 2:03 PM, Warren Kumari wrote: >=20 > On Apr 25, 2013, at 1:34 PM, Pete Resnick = wrote: >=20 >> On 4/25/13 10:42 AM, M=E5ns Nilsson wrote: >>> And IMNSHO spfbis is out of scope prescribing TXT records, just = because >>> of this contagiousness. >>>=20 >>> For the record: I think that the spfbis draft is unfit for = publication >>> as RFC unless TXT records are deprectaed as only carrier of data. >>>=20 >>=20 >> SPFBIS AD hat on for this: >>=20 >> We are *long* past this discussion. This discussion should have = happened at SPFBIS *chartering* time, as it is crystal clear from the = charter that existing features currently in use in SPF are not going = away. Indeed, the TXT record was specifically mentioned in the charter. >>=20 >> I certainly have the same heartburn as everyone else about having = used TXT in this manner, but that ship has long sailed. This is running = and interoperable code and it is being documented on the standards = track. Unless you think there is a piece of information I missed in my = assessment that we had consensus to go forward with this work in the = first place, you are going to have a hard time convincing me that this = is not in the rough part of the consensus now. >=20 > I would also recommend that folk actually go and read RFC6686 [0] - I = know that having actual measurements interferes with one's ability to = have a fun little rant, but, if you do, maybe you can avoid looking = silly (like I did with the RFC5507 discussion :-)). >=20 > Maybe stuffing stuff in a TXT record was a poor decision. Maybe it = wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't = change that, and I'm sure we can find something else more fun to kvetch = about=85 >=20 Ever have one of those days when you just wake up ornery? Those are = probably the days when you shouldn't be responding to mail (or = interacting with people at all) :-P W >=20 > W >=20 > [0]: Yes, I know finding the documents can be hard. Here is a link: = http://tools.ietf.org/html/rfc6686 >=20 >=20 >=20 >> pr >>=20 >> --=20 >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >>=20 >=20 > -- > "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." > -- Terry Pratchett >=20 >=20 >=20 >=20 --=20 A. No Q. Is it sensible to top-post? From drc@virtualized.org Thu Apr 25 11:19:48 2013 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 7D60321F9588 for ; Thu, 25 Apr 2013 11:19: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 pgQFjpKL+75G for ; Thu, 25 Apr 2013 11:19:48 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id EADFD21F8EFC for ; Thu, 25 Apr 2013 11:19:47 -0700 (PDT) Received: from [172.20.10.2] (unknown [166.137.122.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 25B9017166; Thu, 25 Apr 2013 18:19:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <20130425123430.GC18348@mx1.yitter.info> Date: Thu, 25 Apr 2013 13:19:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> <20130425123430.GC18348@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:19:48 -0000 Andrew, On Apr 25, 2013, at 5:34 AM, Andrew Sullivan = wrote: > This conversation should probably move to spfbis@ if we're going to > have it out, but I want to make sure that people who haven't been > following that WG have the appropriate context. Thanks. As mentioned, it would seem minds are made up so I'm not sure = whether it's worth the effort to wade in there. However... > There's actually an interoperability problem, and there's a simple = fact of deployment. =20 There is and will always be an interoperability problem and a 'simple' = fact of deployment. In my view, the issue relevant to DNSEXT ("moribund" or not) is the = implication of the SPFBIS approach on the specification of new DNS = RRtypes. I do not believe the issues faced in SPF deployment are unique = and I imagine there will be protocols in the future that follow the same = steps, i.e., put info in the DNS using TXT during initial experimental = phases because it's easy/simple/doesn't require any = approvals/documentation/interaction with others and then come back later = and try to do "the right thing" when the protocol "works". As I try to be pragmatic, I personally don't get hives about the = underscore-label convention. I don't think it is an ideal choice, but it = does get around broken DPI firewalls/policy that reject unknown RR = types. (of course, SPFBIS doesn't even do this). However, I believe the = implication of the SPFBIS decision is to cement this approach for future = DNS protocol enhancements. This should probably be made clear to RRtype expert reviewers and (if it = doesn't already exist -- quick review of the IANA registries suggests = that it doesn't) a registry should probably be created to avoid = collisions on underscore labels. Of course, I wouldn't put it past DPI = firewall and/or 'security' policy makers to start filtering underscore = labels but so it goes. Hmm. I wonder how many of the DNS User = Interfaces out there disallow underscores in labels...=20 Regards, -drc From Ted.Lemon@nominum.com Thu Apr 25 11:21:53 2013 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 468B721F969C for ; Thu, 25 Apr 2013 11:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 xtCgkITzHSag for ; Thu, 25 Apr 2013 11:21:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEF021F9692 for ; Thu, 25 Apr 2013 11:21:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUXl0Oiic19kxMHrgFfmcgWe0Rv1aRg9U@postini.com; Thu, 25 Apr 2013 11:21:51 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 14A6D1B814E for ; Thu, 25 Apr 2013 11:21:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0C20E190061 for ; Thu, 25 Apr 2013 11:21:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 11:21:46 -0700 From: Ted Lemon To: "dnsext@ietf.org Group" Thread-Topic: [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQUvZmmQ2JXTkhEy3ea4oJfG13ZjmnHmAgAAREQCAAMIRgIAACgkAgAAFUoCAABAwgIAAJxUA Date: Thu, 25 Apr 2013 18:21:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515DA6A@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:21:53 -0000 On Apr 25, 2013, at 12:01 PM, Ted Lemon wrote: > It seems to be the case that there are rather a lot of people on the dnse= xt mailing list who are on the rough side of the consensus here. That sug= gests that perhaps the consensus isn't in the direction that we are presumi= ng it is. There have been a number of rather stiff comments sent to me privately abou= t this statement, particularly with respect to the fact that as AD, I might= have some influence on the consensus call on the SPF document. One perso= n said that I should be very clear about whether I am wearing my AD hat whe= n I make comments like this, which I think is a valid point, and that furth= er, I probably shouldn't make statements like this at all, which I am not s= ure is a valid point; neither am I sure it is not. So to be clear here, the document in question is not a DNSEXT document, and= I am not responsible area director for the working group in which the docu= ment has been considered. Someone proposed that I might be threatening to use my influence as one mem= ber of the IESG to influence the outcome of the consensus call on this docu= ment. To be clear, I was not threatening to do that, and it hadn't occurr= ed to me that someone would think I was threatening to do that. I do unders= tand why someone might have been concerned that I was threatening to do tha= t, and I apologize for having given that impression. As to what I did mean here, what I meant is that I think this is a matter t= hat DNSEXT people are clearly interested in, and there are a lot of DNSEXT = people who think deprecating the SPF record in favor of the TXT record is e= xactly the wrong thing to do, including me with my AD hat off. With my AD hat on, I actually have no clue how to resolve this question. = I've been in working groups where another working group has dogpiled on an = issue. It's certainly appropriate for people who do not agree with the de= precation of the spf record to participate in the spfbis last call, althoug= h you ought to read the document and review the history first. However, there is also an IETF last call, and the purpose of the IETF last = call, as I understand it, is to evaluate whether a document that a working = group has produced actually has consensus within the IETF. As far as I un= derstand it, it is entirely in scope for participants on the dnsext mailing= list to speak up at the IETF last call and say "hey, this is a really bad = idea, here's why." It's my understanding that the responsible AD for the working group whose d= ocument got pushback in IETF last call is supposed to evaluate consensus on= that document; that would be Pete Resnick, not me, so you don't have to wo= rry about my corrupt influence on that process. I don't think IETF last calls often fail to produce consensus, but it did h= appen recently with the MIF DHCP Default Route option. Like this document= , the DHCP Default Route option was in the MIF charter, which had been thro= ugh IETF last call. But when the document itself went though IETF last ca= ll, there was substantial pushback. As a result of this, the document did= not advance. It might be worth considering another related case. Years ago, the DHC wo= rking group proposed a new RRtype, the DHCID RRtype. At the time, existin= g DHCP servers were using TXT records to record identifiers on names so tha= t they could tell whether or not it was safe to do a DNS Update on that nam= e on behalf of a client that was claiming the name. We wrote up a single,= thorough document explaining how to do it, brought it to DNSEXT, and got t= he rotten tomato treatment. Eventually we broke the document up into three pieces, published one as a D= NSEXT (or was it DNSIND?) document, one I think as a DNSOP document, and on= e as a DHC document. At the time of publication, and for many years after= , 100% of implementations used the TXT record, not DHCID. I do not know what the prevalence of DHCID in the field is at this point. = I don't actually care. The standard says the right thing. If existing i= mplementations do something different, that's okay, as long as it works. = Eventually the implementations will get fixed. I think this is the right = outcome for DHCID. It's not exactly analogous to the situation with SPF, = though, where the text record is actually documented in RFC4408. I think you can make an argument for letting this go, or for trying to argu= e the point. I honestly don't know what the right move is=97this debate r= eally should have happened when the spfbis charter was last called. Perha= ps we should take this as a lesson to follow the IETF mailing list more clo= sely=97I certainly didn't notice this when it went by, and I wish I had. = This kind of ships-passing-in-the-night problem happens a lot in the IETF, = and I've never seen a good proposal for how to solve it.= From presnick@qti.qualcomm.com Thu Apr 25 11:54:31 2013 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 4E63921F8411 for ; Thu, 25 Apr 2013 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 jLhgGarIxRjY for ; Thu, 25 Apr 2013 11:54:29 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F221F83DF for ; Thu, 25 Apr 2013 11:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366916069; x=1398452069; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mkP9zT+Pb4M0WaMiLYYBe0d6dt89xP4kSP5Xn/KdxoY=; b=udXox/h+0SYFffSPWPB731QeJObq5Ljjt663UZxrpiY+PnKh0hD+8zZ0 w6/Eu+yNATfEPl0aUzJi93CeDBCyxeWbjPBNDeaCNLTJ7DIM6OgANs1hJ MHKa1DfOSJQsRwVykkW4548uUXtq6cyGAbBRsfYSgeJ0I2+EBxx1CcKO0 A=; X-IronPort-AV: E=Sophos;i="4.87,552,1363158000"; d="scan'208";a="41434567" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 25 Apr 2013 11:54:29 -0700 X-IronPort-AV: E=Sophos;i="4.87,552,1363158000"; d="scan'208";a="438628386" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 11:54:27 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 11:53:47 -0700 Message-ID: <51797BB8.30303@qti.qualcomm.com> Date: Thu, 25 Apr 2013 13:53:44 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077515DA6A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515DA6A@mbx-01.win.nominum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:54:31 -0000 Ted and I spoke a bit about this offline, but just to follow up on a couple of points: On 4/25/13 1:21 PM, Ted Lemon wrote: > However, there is also an IETF last call, and the purpose of the IETF last call, as I understand it, is to evaluate whether a document that a working group has produced actually has consensus within the IETF. As far as I understand it, it is entirely in scope for participants on the dnsext mailing list to speak up at the IETF last call and say "hey, this is a really bad idea, here's why." > It is certainly acceptable to reply to the IETF Last Call, but it is also important to keep in mind what the valid issues to raise are. I intend to make sure that we stay on topic during Last Call, and I will attempt to put appropriate reminders in the Last Call announcement itself. In particular, rehashing issues that ought to have been decided at charter time, or during the Last Call of RFC 6686, are unlikely to be allowed to go on for very long without a clear accounting of new information that has come to light since then. > It's my understanding that the responsible AD for the working group whose document got pushback in IETF last call is supposed to evaluate consensus on that document; that would be Pete Resnick, not me, so you don't have to worry about my corrupt influence on that process. > I think it reasonably likely that I can avoid being corrupted by Ted. ;-) > Perhaps we should take this as a lesson to follow the IETF mailing list more closely—I certainly didn't notice this when it went by, and I wish I had. This kind of ships-passing-in-the-night problem happens a lot in the IETF, and I've never seen a good proposal for how to solve it. > We have been on a long steady drift away from actually doing cross area work (and note that I didn't say "review"; that comes too late) and have become rather silo-ed, and we also seem to have forgotten how to get broad consensus. I've been working on the latter (see ), and I believe the IESG is starting to think about the former. I am more hopeful than I used to be. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Ted.Lemon@nominum.com Thu Apr 25 12:07:56 2013 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 5259B21F96F4 for ; Thu, 25 Apr 2013 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 K4Ymle4xnjuZ for ; Thu, 25 Apr 2013 12:07:55 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C89FB21F96F2 for ; Thu, 25 Apr 2013 12:07:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUXl/CnEBU0hJhOG8mC7HBj9ZzvsUiVeA@postini.com; Thu, 25 Apr 2013 12:07:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3E9FB1B814A for ; Thu, 25 Apr 2013 12:07:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 35AB2190061; Thu, 25 Apr 2013 12:07:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 12:07:54 -0700 From: Ted Lemon To: Pete Resnick Thread-Topic: [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQUvZmmQ2JXTkhEy3ea4oJfG13ZjmnHmAgAAREQCAAMIRgIAACgkAgAAFUoCAABAwgIAAJxUAgAAI8QCAAAPzAA== Date: Thu, 25 Apr 2013 19:07:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515DD8D@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077515DA6A@mbx-01.win.nominum.com> <51797BB8.30303@qti.qualcomm.com> In-Reply-To: <51797BB8.30303@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <375408318A3D154A849B3B3D451C1EF9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 19:07:56 -0000 On Apr 25, 2013, at 2:53 PM, Pete Resnick wrote= : > In particular, rehashing issues that ought to have been decided at charte= r time, or during the Last Call of RFC 6686, are unlikely to be allowed to = go on for very long without a clear accounting of new information that has = come to light since then. So, I'm looking at the charter, and I see nothing in the charter about depr= ecating SPF. Indeed, I see this, which I think forbids deprecating SPF: > Specifically out-of-scope for this working group:=20 > [...] > * Removal of existing features that are in current use.=20 This doesn't seem to be subject to a lot of interpretation. From presnick@qti.qualcomm.com Thu Apr 25 12:15:04 2013 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 C941F21F92C0 for ; Thu, 25 Apr 2013 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 DFmXQBrE-wMS for ; Thu, 25 Apr 2013 12:15:03 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id D65FD21F95F9 for ; Thu, 25 Apr 2013 12:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366917302; x=1398453302; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0jJFxTqUKFE0qxGwPwrMmFb4aF4mI4/SBEm/IP2DKDA=; b=AVjDA8rwFAMWot9epgJ6u9mS78lS8hJK9RfZP06Ce8k42e9LcGa6SF0w P3rH+iB4VDBl2mTTYlhnjf8fuADwv9Uj0rDENAdesBwZ2Z2+Zz7099QRl IJeRD09Ze78Ekf56MjtZEQvKhqPOD+/d+7HzR9M5qj2NCXYdKR/XYAe69 M=; X-IronPort-AV: E=Sophos;i="4.87,552,1363158000"; d="scan'208";a="36709128" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 25 Apr 2013 12:14:52 -0700 X-IronPort-AV: E=Sophos;i="4.87,552,1363158000"; d="scan'208";a="527780782" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 12:14:52 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 12:14:52 -0700 Message-ID: <517980AA.1070509@qti.qualcomm.com> Date: Thu, 25 Apr 2013 14:14:50 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <8D23D4052ABE7A4490E77B1A012B63077515C1B4@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077515DA6A@mbx-01.win.nominum.com> <51797BB8.30303@qti.qualcomm.com> <8D23D4052ABE7A4490E77B1A012B63077515DD8D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515DD8D@mbx-01.win.nominum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 19:15:05 -0000 On 4/25/13 2:07 PM, Ted Lemon wrote: > So, I'm looking at the charter, and I see nothing in the charter about deprecating SPF. Indeed, I see this, which I think forbids deprecating SPF: > > >> Specifically out-of-scope for this working group: >> [...] >> * Removal of existing features that are in current use. >> > This doesn't seem to be subject to a lot of interpretation. > Indeed, and this was a topic of some serious discussion at the time that 6686 was being worked on, and I'll suggest, as some others have, that you read that document to see why the decision was made. (Indeed, this particular charter item was the topic of a rather contentious appeal to the AD that went a different way for a different topic.) And I'd suggest that this is no longer an interesting topic of conversation for DNSEXT. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From paf@frobbit.se Thu Apr 25 13:00:05 2013 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 688EA21F9457; Thu, 25 Apr 2013 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vEe2RFiokxB; Thu, 25 Apr 2013 13:00:05 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id DA5EF21F960E; Thu, 25 Apr 2013 12:59:58 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id 80BD921D7E; Thu, 25 Apr 2013 21:59:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> Date: Thu, 25 Apr 2013 21:59:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:00:05 -0000 On 25 apr 2013, at 20:03, Warren Kumari wrote: > Maybe stuffing stuff in a TXT record was a poor decision. What I tried to explain in RFC5507 was that the real pain(*) is when you = in an RRSet get back more data than what you want, so that you have to = parse the blob of data you get and do whatever you want to do. The selector of what you want can only be in one of the owner, class or = type, and we know the class is sort of not usable, so you are stuck with = type and owner. If now owner is TXT on everything,... The rest is left as an exercise for the reader. Patrik (*) Experience from too extensive use of NAPTR records in various = solutions, and the reason I came up with the URI RRType. From paf@frobbit.se Thu Apr 25 13:02:08 2013 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 BC40921F9457; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQXW7q1rRTWh; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60B21F93E5; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id 2708321CC1; Thu, 25 Apr 2013 22:02:07 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> Date: Thu, 25 Apr 2013 22:02:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCE3691-CA30-4EF9-81AC-B1FA27FFE263@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> To: Warren Kumari X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:02:08 -0000 On 25 apr 2013, at 21:59, Patrik F=E4ltstr=F6m wrote: > The selector of what you want can only be in one of the owner, class = or type, and we know the class is sort of not usable, so you are stuck = with type and owner. If now owner is TXT on everything,... Sigh...if now TYPE is TXT on everything...of course... Patrik -- going to bed now From dougb@dougbarton.us Thu Apr 25 13:54:40 2013 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 ADCD221F9670; Thu, 25 Apr 2013 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 ndMKZJrB1YxO; Thu, 25 Apr 2013 13:54:40 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2521F965F; Thu, 25 Apr 2013 13:54:39 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id 98B2622BA3; Thu, 25 Apr 2013 20:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366923279; bh=/lxC1rSFs1cM9IOfLanu8/jAulxNybK0yU4gHP6o6VA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=SKCC7UKqWxyJg2AEwvd1B8DmNqDWfWPDKge3rJgDT9Uyb5pmJE8uj4NmY8PYksduh zDPWJJMx76ZKoIauzkOc211OvjTeIsxuNcduPieeAPg9e0c7rMPDSxiNq/PN8P2IXF S4su5rT8Z6b0pLKlb61NCwCFZUDtAVlBd85gZGr0= Message-ID: <5179980F.9090606@dougbarton.us> Date: Thu, 25 Apr 2013 13:54:39 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> In-Reply-To: <5179691B.50602@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, presnick@qti.qualcomm.com Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:54:40 -0000 On 04/25/2013 10:34 AM, Pete Resnick wrote: > On 4/25/13 10:42 AM, Måns Nilsson wrote: >> And IMNSHO spfbis is out of scope prescribing TXT records, just because >> of this contagiousness. >> >> For the record: I think that the spfbis draft is unfit for publication >> as RFC unless TXT records are deprectaed as only carrier of data. > > SPFBIS AD hat on for this: > > We are *long* past this discussion. This discussion should have happened > at SPFBIS *chartering* time, as it is crystal clear from the charter > that existing features currently in use in SPF are not going away. > Indeed, the TXT record was specifically mentioned in the charter. As Ted pointed out, that seems not to be the case. Meanwhile, some of us have spoken long and loud about how deprecating the SPF record is the wrong path, which includes before, during, and after spfbis was chartered. Those concerns have consistently been shouted down, as you are doing now. The way forward is simple, spfbis should specify that compliant senders MUST publish the SPF record, and compliant receivers MUST query for it first. Then down the road at some point we can deprecate TXT for this purpose. If that had been done in the beginning we would be celebrating the deprecation of the TXT record right about now, instead of having another round of contentious arguments about doing it the right way in the first place. Everyone knows the history of how hard it was to get new RRtypes off the ground at the time SPF first came into being. A lot of lessons were learned from that, and the situation is much better now. Everyone also understands that the problem of upgrading 3rd party and/or web-based provisioning systems to accommodate new records is still a problem. But that problem doesn't get better by ignoring it. In short, the proponents of SPF (which by the way, I like and use) should be focusing on doing the right thing here, instead of the expedient thing. Doug From superuser@gmail.com Thu Apr 25 14:09:50 2013 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 77D1221F96CB; Thu, 25 Apr 2013 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 nh0lkiJsjb-6; Thu, 25 Apr 2013 14:09:49 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4E621F96CA; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so3927310wie.12 for ; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ukdn7kuBj8BLAuYGR1MP0GzJdljV/bkcqGfU8UwwLZo=; b=lfj4Uc8an7FyDOAifeUo/6nhXjuLrxHW7ZM5zRYlGihMRCIdlMCAGtClSc4fTZDhtJ W1Adf+jRDvkva57kJkr7Ccp9QzdJFW0XxrTiUe5oFGjr+++t3J2/NltV8Qp9U3Gnh2zl nzff7gfipCKTLXht9X61F1P7szl+zHWp6KkWbfdmQqVUjuqBA/7Et9nIcMUjCnFHUBJY waWFhmcZVK87ud7VxgFT9F59PBqIxjGSg8LLzkhforNDr5XXajJXo2cjMTYWnJFtURDj 4VYrVTVguzTi9xSK4LHGIfTfbda/j4uBbR5cjiL7UvdBr7YiSxrHX6tu6MZ2A3fSghmU tB5Q== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr165478wic.32.1366924188225; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 14:09:47 -0700 (PDT) In-Reply-To: <5179980F.9090606@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> Date: Thu, 25 Apr 2013 14:09:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=001a11c34830ac988f04db35d64d Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:09:50 -0000 --001a11c34830ac988f04db35d64d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton wrote: > The way forward is simple, spfbis should specify that compliant senders > MUST publish the SPF record, and compliant receivers MUST query for it > first. Then down the road at some point we can deprecate TXT for this > purpose. If that had been done in the beginning we would be celebrating the > deprecation of the TXT record right about now, instead of having another > round of contentious arguments about doing it the right way in the first > place. > > I fail to see how the word "simple" can be legitimately applied here given the breadth of the deployed base of SPF that's using TXT. It may be the right thing to do, but I don't think that's a mountain that's easy to move. Certainly it's easy to talk about it though. > > Everyone knows the history of how hard it was to get new RRtypes off the > ground at the time SPF first came into being. A lot of lessons were learned > from that, and the situation is much better now. Everyone also understands > that the problem of upgrading 3rd party and/or web-based provisioning > systems to accommodate new records is still a problem. But that problem > doesn't get better by ignoring it. > > In short, the proponents of SPF (which by the way, I like and use) should > be focusing on doing the right thing here, instead of the expedient thing. > I think that same history gives rise to another way forward. When SPF came into being, the RRtype issue prevented the right thing from happening. It was made worse by late insertion of a sloppy transition mechanism. It's much too late to fix that now, but we can take steps to prevent it from happening with future protocols. Thus: Take our licks and leave this one alone, but do good work on improving process and provisioning so that it can't happen again. -MSK --001a11c34830ac988f04db35d64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <dougb@dou= gbarton.us> wrote:
The way forward is s= imple, spfbis should specify that compliant senders MUST publish the SPF re= cord, and compliant receivers MUST query for it first. Then down the road a= t some point we can deprecate TXT for this purpose. If that had been done i= n the beginning we would be celebrating the deprecation of the TXT record r= ight about now, instead of having another round of contentious arguments ab= out doing it the right way in the first place.


I fail to see how the word "= ;simple" can be legitimately applied here given the breadth of the dep= loyed base of SPF that's using TXT.=A0 It may be the right thing to do,= but I don't think that's a mountain that's easy to move.=A0 Ce= rtainly it's easy to talk about it though.
=A0

Everyone knows the history of how hard it was to get new RRtypes off the gr= ound at the time SPF first came into being. A lot of lessons were learned f= rom that, and the situation is much better now. Everyone also understands t= hat the problem of upgrading 3rd party and/or web-based provisioning system= s to accommodate new records is still a problem. But that problem doesn'= ;t get better by ignoring it.

In short, the proponents of SPF (which by the way, I like and use) should b= e focusing on doing the right thing here, instead of the expedient thing.

I think that same history gives rise to another way for= ward.=A0 When SPF came into being, the RRtype issue prevented the right thi= ng from happening.=A0 It was made worse by late insertion of a sloppy trans= ition mechanism.=A0 It's much too late to fix that now, but we can take= steps to prevent it from happening with future protocols. Thus: Take our l= icks and leave this one alone, but do good work on improving process and pr= ovisioning so that it can't happen again.

-MSK
--001a11c34830ac988f04db35d64d-- From johnl@iecc.com Thu Apr 25 14:38:47 2013 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 44C4721F9699 for ; Thu, 25 Apr 2013 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.6 X-Spam-Level: X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 JFZGH3v+gyrd for ; Thu, 25 Apr 2013 14:38:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5921F9674 for ; Thu, 25 Apr 2013 14:38:46 -0700 (PDT) Received: (qmail 97191 invoked from network); 25 Apr 2013 21:38:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2013 21:38:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5179a265.xn--3zv.k1304; i=johnl@user.iecc.com; bh=A8+CswciSGcBxqfHOKRdvlue3mwBNiKXo0HKoT2J5qw=; b=K7POr/sl9pYhHEGII06fc31EsGP983MJ0J3Tx45IvNrUP2luL1MCh9LaCGKDdLrmdNTeOywwT29iw4kOWEGaKeluTqWcmtUYO8PhNsrW5nYCrYa9POM3HeeY8iQhWxGxCa+/+i6UPIdulaXJ3G6qIdpWGB2YoHIyY8ceKn+CzlU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5179a265.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=A8+CswciSGcBxqfHOKRdvlue3mwBNiKXo0HKoT2J5qw=; b=OaqZ9dpyK2u339wGZey2MYGTcpDsH/FpcEPeSi9Y2MEqmGM0YsVVZ03YOXitaazV+GyqH3BbkVu0g0TPReiRF+796vI7csZM/Uyw/Rql2QF7LFAj2UEHkrEZbf3pds4nn2t8XE2lazNZrc3TXmz+X8+m9sOXzHTW16yVrEOcPqM= Date: 25 Apr 2013 21:38:23 -0000 Message-ID: <20130425213823.66741.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <517960CE.70604@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:38:47 -0000 >SPF has one important benefit that DKIM cannot, reduction of >joe-jobbing. I used to get backscatter at the rate of at least 2-3 per >day, with peaks of 10-20. After adding an SPF record with the hard-fail >option that's down to a couple per month. Gee, on a bad day I used to get 300,000, mostly from parts of the world where SPF still isn't very widely used. (Yes. that's the right number of zeros.) Now it's down to an insignificant 250 or so, mostly because the spammer who used to forge my address in all his spam has gone on to other stuff. Look, we all understand why glomming everything into TXT records is not ideal. If we were defining SPf from scratch, and the time to get new rrtypes into provisioning systems were measured in months rather than decades, we'd likely have done something else. But we aren't, and it's not. R's, John From dougb@dougbarton.us Thu Apr 25 14:39:49 2013 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 A5F0C21F970F; Thu, 25 Apr 2013 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 FA3-fnPEGdP0; Thu, 25 Apr 2013 14:39:49 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id E542221F96CB; Thu, 25 Apr 2013 14:39:48 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id 94FEA22BA3; Thu, 25 Apr 2013 21:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366925988; bh=RKKRNK/x9v4TndQFLyV8fb6Hl2P15u1iVKXKIVkBL9M=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IZeTARzfAp4t1wY6R0190dKziyj36iC4mVntrnKObT7Si+fX/PrgoL6mcbKiXxSc0 wFH//2tHOGfWggMvKNz1awwfoj9ffbU+ocaAE4Hjke5hTRDGkg7AOcGWF5AscrltG0 f5uWBB81xGp1YaG7dpdjoGwQMHs8BTk2d7gwLQUE= Message-ID: <5179A2A4.1090606@dougbarton.us> Date: Thu, 25 Apr 2013 14:39:48 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:39:49 -0000 On 04/25/2013 02:09 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton > wrote: > > The way forward is simple, spfbis should specify that compliant > senders MUST publish the SPF record, and compliant receivers MUST > query for it first. Then down the road at some point we can > deprecate TXT for this purpose. If that had been done in the > beginning we would be celebrating the deprecation of the TXT record > right about now, instead of having another round of contentious > arguments about doing it the right way in the first place. > > > I fail to see how the word "simple" can be legitimately applied here > given the breadth of the deployed base of SPF that's using TXT. I didn't say "Don't query for TXT records any more." I definitely didn't say, "Let's throw out SPF altogether." I said "change it to go the right way around in the first place." Obviously the transition will take time (as I also pointed out), but that doesn't mean that we shouldn't start doing it the right way now. And really, it IS simple. Tomorrow all the extant software that deals with SPF gets updated to query for SPF first. The next day all the docs for publishing SPF records tell people to publish both. Ok, tomorrow and the next day are probably not realistic, but how about next week? Or next month? This isn't brain surgery, it really is a very simple change. And sure it's going to take time to implement, time to upgrade the installed base, and time for the pendulum to swing from TXT being queried nearly universally to SPF instead. But it's a minimal amount of effort, and the time is going to pass anyway. There is simply no reason not to do this right, and to start doing it right now. > It may > be the right thing to do, but I don't think that's a mountain that's > easy to move. Certainly it's easy to talk about it though. We in the DNS world have a ton of experience with the long tail of an installed base that doesn't upgrade often. Maybe that's the difference in perspective that makes this look like an "easy" problem to us. > Everyone knows the history of how hard it was to get new RRtypes off > the ground at the time SPF first came into being. A lot of lessons > were learned from that, and the situation is much better now. > Everyone also understands that the problem of upgrading 3rd party > and/or web-based provisioning systems to accommodate new records is > still a problem. But that problem doesn't get better by ignoring it. > > In short, the proponents of SPF (which by the way, I like and use) > should be focusing on doing the right thing here, instead of the > expedient thing. > > > I think that same history gives rise to another way forward. When SPF > came into being, the RRtype issue prevented the right thing from > happening. I would argue that the situation at the time made doing the right thing more difficult than using the TXT record, not that it made it impossible. But I will agree to disagree on that point. :) > It was made worse by late insertion of a sloppy transition > mechanism. It's much too late to fix that now But it's not. That's the point. I realize that the course of action where we throw up our hands and say to ourselves, "better luck next time, hopefully this will become a lesson learned" is wildly attractive. But it's bad to do that. Bad for SPF, bad for the DNS in general, and bad for the Internet as a whole. And most importantly, it would be choosing to do the wrong thing when there is no reason not to do the right thing. Doug From johnl@taugh.com Thu Apr 25 14:58:32 2013 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 38C0721F9616 for ; Thu, 25 Apr 2013 14:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 rq2MSZxm0Qpu for ; Thu, 25 Apr 2013 14:58:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9125021F8517 for ; Thu, 25 Apr 2013 14:58:31 -0700 (PDT) Received: (qmail 1060 invoked from network); 25 Apr 2013 21:58:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=423.5179a707.k1304; bh=CXIdLmMRTUfP+9020XARC76D7gm7WpLwIXarE6uoe8w=; b=GhzyPIAsDUt3NIpF0F57FLTq36BgTH7ZbJV4d7eqoljKB379sca7elDTPTFYOCiKS0lvDLaAmiNijhnHIwQL9dVVKALOTKZ4iIDlsjADm9biWmnF0J2co/JoyxLXo5GrOgwR2bd8b3uZi5mn0gImhegczWAsf6SIQjlbUmQv2HM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=423.5179a707.k1304; bh=CXIdLmMRTUfP+9020XARC76D7gm7WpLwIXarE6uoe8w=; b=zsCARygQ1uiZI4R67GrIwL5k2iaimu+HPBA/r1wOmRmANmHvK5ZcQaWo7E6x36gdDNWcmKcZmf2ujvXeIrexNVg+0un3RqmidGNoqq5SKrormPwcmK3sWVNbdAUjqMRrDaYkMOtDAUwMkeH+2kUdXuvke16wp6qypZbsouaDhvs= Received: (ofmipd 127.0.0.1); 25 Apr 2013 21:58:09 -0000 Date: 25 Apr 2013 17:58:30 -0400 Message-ID: From: "John R Levine" To: dnsext@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 25 Apr 2013 21:58:32 -0000 >In my view, the issue relevant to DNSEXT ("moribund" or not) is the implication of the SPFBIS approach >on the specification of new DNS RRtypes. I do not believe the issues faced in SPF deployment are unique >and I imagine there will be protocols in the future that follow the same steps, i.e., put info in the >DNS using TXT during initial experimental phases because it's easy/simple/doesn't require any >approvals/documentation/interaction with others and then come back later and try to do "the right >thing" when the protocol "works". Indeed. What could we do to encourage people to use new RRTYPEs from the beginning of their experiments? Wagging fingers, insulting people, and asserting that there is no barrier to installing new versions of software has a proven track record of failure. Perhaps we could identify the actual bottlenecks (if you've read my previous zillion messages you know what I have in mind) and figure out how to fix them. R's, John From hsantos@isdg.net Thu Apr 25 14:58:33 2013 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 0AA1621F8517 for ; Thu, 25 Apr 2013 14:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 GoK811uBLigk for ; Thu, 25 Apr 2013 14:58:32 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7921F85ED for ; Thu, 25 Apr 2013 14:58:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3517; t=1366927108; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=nVT6TLm UuQeN+oNuQZhnhH7E6BI=; b=i7PcWcr7T5o+qtE/NTwdNgo2eQUKYcIs1EIDU8h 4H3QFT+18Og885yo5aByxHLh6XD9Sjq87Ig7r2ArZLIwtQsAsvkWG2k+o3tQmTMA IlrdV+OntbPY45UvDPc2lQl7OVydqi8M1hFdTewk8Uqe2WHuhZ7vayigjwNgk8sF GMBU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Thu, 25 Apr 2013 17:58:28 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1425830138.615.4172; Thu, 25 Apr 2013 17:58:27 -0400 Message-ID: <5179A6B4.7030600@isdg.net> Date: Thu, 25 Apr 2013 17:57:08 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:58:33 -0000 I believe the right engineering design choice in MARID was made. The problem was the DNS Servers have not caught up with the very least of having a passthru concept with unnamed query types. It is was clearly known what the issues were in MARID, a migration path was provided with the protocol and we fully expected the DNS servers will eventually catch up and support unnamed types. [1] It was a long term migration path issue as Doug Barton pointed out. I still believe having a specific record is the right thing and path. Eliminating it will only encourage more TXT-based protocols. The question is whether the DNS servers will support it or at the very least a passthru. I suggest to keep it and to relax the requirements, and basically have developers keep it as an software design option, i.e. don't forget about it, comment it out, compiler directives, etc. It would be their choice to immediately support the ideal migration path that is currently described in 4408 (although I have a small issue with the parallel call idea, but that's a different issue), or leave the code ready but disable it for a TXT only query. Lets think ahead here now (again), not later and begin to encourage DNS server developers/vendors, DNS Managerment Software folks, etc, to support unnamed types processing. [1] -- HLS [1] http://tools.ietf.org/html/rfc3597 n 4/25/2013 5:09 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton wrote: > >> The way forward is simple, spfbis should specify that compliant senders >> MUST publish the SPF record, and compliant receivers MUST query for it >> first. Then down the road at some point we can deprecate TXT for this >> purpose. If that had been done in the beginning we would be celebrating the >> deprecation of the TXT record right about now, instead of having another >> round of contentious arguments about doing it the right way in the first >> place. >> >> > I fail to see how the word "simple" can be legitimately applied here given > the breadth of the deployed base of SPF that's using TXT. It may be the > right thing to do, but I don't think that's a mountain that's easy to > move. Certainly it's easy to talk about it though. > > >> >> Everyone knows the history of how hard it was to get new RRtypes off the >> ground at the time SPF first came into being. A lot of lessons were learned >> from that, and the situation is much better now. Everyone also understands >> that the problem of upgrading 3rd party and/or web-based provisioning >> systems to accommodate new records is still a problem. But that problem >> doesn't get better by ignoring it. >> >> In short, the proponents of SPF (which by the way, I like and use) should >> be focusing on doing the right thing here, instead of the expedient thing. >> > > I think that same history gives rise to another way forward. When SPF came > into being, the RRtype issue prevented the right thing from happening. It > was made worse by late insertion of a sloppy transition mechanism. It's > much too late to fix that now, but we can take steps to prevent it from > happening with future protocols. Thus: Take our licks and leave this one > alone, but do good work on improving process and provisioning so that it > can't happen again. > > -MSK > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From presnick@qti.qualcomm.com Thu Apr 25 15:41:22 2013 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 454B421F9707; Thu, 25 Apr 2013 15:41:22 -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 BvoEVMp9Y+I3; Thu, 25 Apr 2013 15:41:21 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6121F96FB; Thu, 25 Apr 2013 15:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366929681; x=1398465681; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=a/AYLIclim3tXn690H0jl64Gk5TLsvK7/8PsPmbA7Tg=; b=F7aQZD3A/U4/cDwmzbKBJA69LDSodT3gNrWA1y6PhJR8HSXlONgk9rjg 6hOiyb5KaAexDnFRCikQTncMXgpQCBvMD0fsc0r7PSfVPLUWeIwB9FTgB WNu5tIuKLBbWPh5rIN2poEoxkH3c7T+Zbsff5zvXJOjupmq6a4LGgVFMj E=; X-IronPort-AV: E=Sophos;i="4.87,553,1363158000"; d="scan'208";a="36760509" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 25 Apr 2013 15:41:20 -0700 X-IronPort-AV: E=Sophos;i="4.87,553,1363158000"; d="scan'208";a="527920051" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 15:41:20 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 15:41:20 -0700 Message-ID: <5179B10E.705@qti.qualcomm.com> Date: Thu, 25 Apr 2013 17:41:18 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Doug Barton References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: <5179980F.9090606@dougbarton.us> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 22:41:22 -0000 On 4/25/13 3:54 PM, Doug Barton wrote: > On 04/25/2013 10:34 AM, Pete Resnick wrote: >> On 4/25/13 10:42 AM, Måns Nilsson wrote: >>> And IMNSHO spfbis is out of scope prescribing TXT records, just because >>> of this contagiousness. >>> >>> For the record: I think that the spfbis draft is unfit for publication >>> as RFC unless TXT records are deprectaed as only carrier of data. >> >> SPFBIS AD hat on for this: >> >> We are *long* past this discussion. This discussion should have happened >> at SPFBIS *chartering* time, as it is crystal clear from the charter >> that existing features currently in use in SPF are not going away. >> Indeed, the TXT record was specifically mentioned in the charter. > > As Ted pointed out, that seems not to be the case. Ted and I just had a discussion about this offline, and just as Ted did, you have misread what I wrote. I responded to Måns's suggestion that spfbis can not "prescribe TXT records". And I responded that existing features currently in use in SPF (of which the use of TXT is such a feature) are out of charter to remove. And they are. The removal of the feature to use RR 99 was an option open to the WG if they determined that it was not on the forbidden list of "features currently in use". RFC 6686 and the discussion leading up to it document why it is, for all intents and purposes, unused. > Meanwhile, some of us have spoken long and loud about how deprecating > the SPF record is the wrong path, which includes before, during, and > after spfbis was chartered. Those concerns have consistently been > shouted down, as you are doing now. A few things on this point: 1. There is no doubt that the removal of the feature to use RR 99 engendered a protracted and contentious discussion. However, it was not specifically discussed before or during chartering as far as I can tell. I've looked through the IETF list, the IESG list, the DNSEXT list, and the SPFBIS list and I see nothing on this topic discussed prior to chartering. And importantly, I see not a single message from you in particular on this topic prior to this, and only a few messages in September of last year on any SPF topic. So I'm not clear on what you mean by "some of us" having "spoken long and loud" about this topic before or during SPFBIS being chartered. 2. There is also no doubt that during the long discussion in February of last year on the SPFBIS list, many folks expressed the view that the feature ought not be removed, including by at least one chair of the WG. (In fact, that argument drove some of the research that ended up in RFC 6686.) However, in the end, a consensus call was made that, although there were some outstanding objections, those concerns were sufficiently addressed *by reasoned technical argument* and that the consensus (with some roughness) was that the feature was to be removed. Though there may have been shouting at times, there was no "shouting down". 3. I do not intend, and hope I have not, "shouted down" any argument here. However, there is now a long record on this argument and how the consensus call was made. Though the chairs and I will review all discussion that comes out during Last Call (or now), it really is only polite for (if not incumbent on) those who might still have objections to do some research to see if their particular argument was not addressed in that lengthy discussion. My claim in my earlier message was (and remains) that it's going to take identifying some piece of information that was missed during that discussion to convince me that the consensus call was not correct. As I've said elsewhere, number of people saying something is not how consensus is judged; it's whether the issue itself was properly addressed. (See draft-resnick-on-consensus-02 for my musings on that.) Coming to consensus is hard work, and it shouldn't just be hard work for chairs and ADs; participants have to do their part too. In particular: > The way forward is simple, spfbis should specify that compliant > senders MUST publish the SPF record, and compliant receivers MUST > query for it first. Then down the road at some point we can deprecate > TXT for this purpose. This is *not* a new argument. It was one that was discussed at length on the SPFBIS list at the end of last February. If you think we missed something (and I'd really ask you to read through the discussion of issue #9 on the list), I'd encourage you to make that case. But simply saying, "MUST publish/MUST query/later deprecate TXT" is not a sufficient technical argument given all that has been discussed to date. > In short, the proponents of SPF (which by the way, I like and use) > should be focusing on doing the right thing here, instead of the > expedient thing. If, after reading the discussion, you think SPFBIS was being superficial in its treatment of this topic and can identify an argument that was missed, fine. But your presumption that this was done simply for expedience is at the very least premature. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From drc@virtualized.org Thu Apr 25 15:46:21 2013 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 039B021F970F for ; Thu, 25 Apr 2013 15:46:21 -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 0FkH3+TF7-lz for ; Thu, 25 Apr 2013 15:46:20 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5B62A21F8C14 for ; Thu, 25 Apr 2013 15:46:20 -0700 (PDT) Received: from [10.0.1.2] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id D46F417166; Thu, 25 Apr 2013 22:46:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <33B808F3-C826-4EBC-8AF5-3E9CE669407B@vpnc.org> Date: Thu, 25 Apr 2013 17:46:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <33B808F3-C826-4EBC-8AF5-3E9CE669407B@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: S Moonesamy , DNSEXT Working Group Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 22:46:21 -0000 Paul, On Apr 25, 2013, at 8:33 AM, Paul Hoffman wrote: >> Is the annotation in the DNS Parameters registry correct? > Yes, it is correct. >=20 > Isn't it amazing that the DNSEXT WG can't answer a simple question = without turning it into a lecture about How Things Would Be Done If We = Were Kings and Queens? (Actually, no one even bothered to answer the = question...) Err, might want to step down off that high horse: might be causing = cerebral hypoxia. :) In my response that seems to have touched off this thread, I stated:=20 "It is in keeping with past practice, e.g., see the notations for MD, = MF, A6, and the MAILA RRtypes at = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml." I'd also point out some inconsistencies in the registry (e.g., NXT = should probably say "OBSOLETE - use NSEC") and sillinesses (e.g., what's = the point of replicating the RR type's name as the meaning?) but that's = probably something for a different thread. Regards, -drc From dougb@dougbarton.us Thu Apr 25 16:28:52 2013 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 4D1F621F96A8; Thu, 25 Apr 2013 16:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 18NbxykZoKl4; Thu, 25 Apr 2013 16:28:51 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 03E0521F968B; Thu, 25 Apr 2013 16:28:51 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id ADFBA22BA3; Thu, 25 Apr 2013 23:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366932530; bh=7rYngVGG544ALrcvvGlrARPqPahX4hLmApm1qrQdTi8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IjN8cU4qKtxU2Yz/JmlccsJerHcDmSNUNC1gT9uvHvvgQxJHN1F/phSdvqzl5rABi tIOI7WPS1xlbYtnWplAdv4/XawTvdC2VH21E1nBuP2lKDXqWGKl+r+maLTqSQzmxBy U7Iee5WML4MNls6qAi2YLHSzrfIeIEoSG5BsUcMQ= Message-ID: <5179BC32.8050205@dougbarton.us> Date: Thu, 25 Apr 2013 16:28:50 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> In-Reply-To: <5179B10E.705@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 23:28:52 -0000 On 04/25/2013 03:41 PM, Pete Resnick wrote: > On 4/25/13 3:54 PM, Doug Barton wrote: >> On 04/25/2013 10:34 AM, Pete Resnick wrote: >>> On 4/25/13 10:42 AM, Måns Nilsson wrote: >>>> And IMNSHO spfbis is out of scope prescribing TXT records, just because >>>> of this contagiousness. >>>> >>>> For the record: I think that the spfbis draft is unfit for publication >>>> as RFC unless TXT records are deprectaed as only carrier of data. >>> >>> SPFBIS AD hat on for this: >>> >>> We are *long* past this discussion. This discussion should have happened >>> at SPFBIS *chartering* time, as it is crystal clear from the charter >>> that existing features currently in use in SPF are not going away. >>> Indeed, the TXT record was specifically mentioned in the charter. >> >> As Ted pointed out, that seems not to be the case. > > Ted and I just had a discussion about this offline, and just as Ted did, > you have misread what I wrote. I responded to Måns's suggestion that > spfbis can not "prescribe TXT records". And I responded that existing > features currently in use in SPF (of which the use of TXT is such a > feature) are out of charter to remove. And they are. ... and for the Nth repetition, I did not propose to remove the TXT record at this time. > The removal of the feature to use RR 99 was an option open to the WG if > they determined that it was not on the forbidden list of "features > currently in use". RFC 6686 and the discussion leading up to it document > why it is, for all intents and purposes, unused. Yep, been there, done that. It was a bad decision then, and it's still a bad decision now. I realize that it's incredibly unpopular to bluntly call bad decisions "bad decisions," but not doing so doesn't make them any less bad. And, to make matters worse, not doing so has led to a non-trivial number of those bad decisions becoming de facto standards. This has at least 2 very bad side effects ... first, we have to live with the bad de facto standards; but more importantly we are providing encouragement to people who wish to make similar bad decisions down the road. The argument in 6686 boils down to, "We made a series of bad decisions, which have led to a bad result. We now want to codify that bad result instead of cleaning up our mess." I don't agree with that in principle, and I don't agree with that in regards to this particular case. Further, while cleaning up the SPF mess would require nothing more than a marginal amount of extra work now, plus the passage of time, there is no reason not to actually clean up the mess. >> Meanwhile, some of us have spoken long and loud about how deprecating >> the SPF record is the wrong path, which includes before, during, and >> after spfbis was chartered. Those concerns have consistently been >> shouted down, as you are doing now. > > A few things on this point: > > 1. There is no doubt that the removal of the feature to use RR 99 > engendered a protracted and contentious discussion. However, it was not > specifically discussed before or during chartering as far as I can tell. > I've looked through the IETF list, the IESG list, the DNSEXT list, and > the SPFBIS list and I see nothing on this topic discussed prior to > chartering. https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is where the thread starts. There is another parallel thread an a related topic around that same time. > And importantly, I see not a single message from you in > particular on this topic prior to this, https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html > and only a few messages in > September of last year on any SPF topic. So I'm not clear on what you > mean by "some of us" having "spoken long and loud" about this topic > before or during SPFBIS being chartered. With respect, you clearly haven't been paying attention. That thread on ietf@ (and the one you referenced on dnsext) took me about 2 minutes to find. Admittedly, the ietf@ thread wasn't specifically about SPF, but it was about the same exact topic, at the time that the spfbis charter was being developed, so one would think that interested parties would have wanted to pay attention. The topic has been raised numerous times since day 1 of SPF, and the DNS folk who have said "the SPF RRtype should be the first (if not only) choice" have been consistently ignored. Meanwhile, who said what when isn't the interesting part of the discussion. The questions are simple: 1. What is the right thing to do? 2. Can we do it? We know the answer to 1, and the answer to 2 is yes. So why are we spending all of this time trying to find reasons not to do the right thing? If as much energy had gone into fixing the problem as has gone into justifying not fixing the problem, the problem would be fixed by now. :) > 2. There is also no doubt that during the long discussion in February of > last year on the SPFBIS list, many folks expressed the view that the > feature ought not be removed, including by at least one chair of the WG. > (In fact, that argument drove some of the research that ended up in RFC > 6686.) However, in the end, a consensus call was made that, although > there were some outstanding objections, those concerns were sufficiently > addressed *by reasoned technical argument* and that the consensus (with > some roughness) was that the feature was to be removed. Yes, I know the history. It was a bad decision. The great thing about life, especially life in the IETF, is that bad decisions can be revisited. > Though there may > have been shouting at times, there was no "shouting down". Others see the problem differently, but let's not quibble on that point. > 3. I do not intend, and hope I have not, "shouted down" any argument > here. However, there is now a long record on this argument and how the > consensus call was made. Though the chairs and I will review all > discussion that comes out during Last Call (or now), it really is only > polite for (if not incumbent on) those who might still have objections > to do some research to see if their particular argument was not > addressed in that lengthy discussion. My claim in my earlier message was > (and remains) that it's going to take identifying some piece of > information that was missed during that discussion to convince me that > the consensus call was not correct. As I've said elsewhere, number of > people saying something is not how consensus is judged; it's whether the > issue itself was properly addressed. (See draft-resnick-on-consensus-02 > for my musings on that.) Coming to consensus is hard work, and it > shouldn't just be hard work for chairs and ADs; participants have to do > their part too. > > In particular: > >> The way forward is simple, spfbis should specify that compliant >> senders MUST publish the SPF record, and compliant receivers MUST >> query for it first. Then down the road at some point we can deprecate >> TXT for this purpose. > > This is *not* a new argument. It was one that was discussed at length on > the SPFBIS list at the end of last February. If you think we missed > something (and I'd really ask you to read through the discussion of > issue #9 on the list), I'd encourage you to make that case. I'll give that a go, sure. > But simply > saying, "MUST publish/MUST query/later deprecate TXT" is not a > sufficient technical argument given all that has been discussed to date. But what if all of the previous discussion was wrong? Simply saying "we have discussed this extensively" doesn't refute sound technical arguments either. :) >> In short, the proponents of SPF (which by the way, I like and use) >> should be focusing on doing the right thing here, instead of the >> expedient thing. > > If, after reading the discussion, you think SPFBIS was being superficial > in its treatment of this topic and can identify an argument that was > missed, fine. But your presumption that this was done simply for > expedience is at the very least premature. While I didn't follow the spfbis group, I have followed SPF from the time before it was even a topic at the IETF. Given what I know of the history I stand by my assertion, but would be overjoyed to be proven wrong. Doug From dougb@dougbarton.us Thu Apr 25 17:15:46 2013 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 1A27D21F9080; Thu, 25 Apr 2013 17:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, 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 JcwSRjWKEGYJ; Thu, 25 Apr 2013 17:15:45 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id E140321F8AD5; Thu, 25 Apr 2013 17:15:44 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 3447822BA3; Fri, 26 Apr 2013 00:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366935344; bh=kI3CLRIafveYkF4joKnhr5ZSoqI3uB6Ma3lp8WR2LLo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=wAv9Qf8yqQikJ/JPmlrlf3sApTY5SEdWwjy7G8S8rI5PRUbYqryZuz5JCYZuha56X thihi8RKhKZi6j9uM0IdzS9mbUEq3QZ91vVFuU7b1rhLROfC/niGdBrqLIBH+R9AL/ nQPhWbvaRQ0HqiaRAukuFmaR1GQ0re3u3UJfP0hY= Message-ID: <5179C72F.1070703@dougbarton.us> Date: Thu, 25 Apr 2013 17:15:43 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> In-Reply-To: <5179B10E.705@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 00:15:46 -0000 On 04/25/2013 03:41 PM, Pete Resnick wrote: > and I'd really ask you to read through the discussion of issue #9 on the > list Ok, so I've read through those threads, and the antecedents. I saw the following: 1. Some reports of people who wrote code to use the new RRtype early on, and had problems, so they stopped. 2. A report that Perl's "Mail::SPF (which is used by Spamassassin) checks for Type SPF first by default." 3. Several folks pointing out the valid DNS protocol based reasons why overloading TXT is bad, and new RRtypes for new features are good. 4. Lots of messages along the lines of, "We've always used TXT for this, so we should keep using it." These arguments all seem focused around the concept that having 2 ways to do the same thing is kind of a pain, so let's just use the one that is most popular. 5. Some fairly persuasive technical arguments from Andrew Sullivan that putting SPF records into your zone is a good idea. Particularly this: https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html #1 was an expected result in the days prior to 3597 (2003), but should be little to no trouble now. #2 Speaks in favor of my proposal. #3 (Arguably one of the only "reasoned technical arguments" in the bunch) seems to have been ignored by the majority of list members. #4 Is not a "reasoned technical argument." #5 Is also a "reasoned technical argument," which was not only ignored, but twisted on its ear by at least one list member. It's also worth pointing out that a non-zero number of list members were ready (eager?) to shut down the SPF record prior to their being any actual discussion of it. So I stand by my original proposal. We should do the right thing here, not the expedient thing. And the fact that a significant piece of software is already doing that, and clearly it works, is a pretty big point in favor. Further, there were no "reasoned technical arguments" in that thread against doing what I proposed. As I mentioned in #4 above there was some whinging about having 2 ways to do the lookup, but as I pointed out previously if the switch had been flipped to do the SPF lookup first at some reasonable time post-3597, we'd be celebrating the deprecation of the TXT record right about now. And further than _that_, Andrew and a few other list members pointed out that with a theoretical v=spf3 on the horizon, that would be a perfect time to say "Use the SPF record only, don't use TXT at all." Of course that whole line of thought was shot down with the same, "But we've always used TXT" argument. Which is unfortunate because I think that would have been an excellent compromise position, which has valid technical grounds. Doug From marka@isc.org Thu Apr 25 17:46:53 2013 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 D214921F9745 for ; Thu, 25 Apr 2013 17:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzviqSNpIB6o for ; Thu, 25 Apr 2013 17:46:53 -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 0412321F92C0 for ; Thu, 25 Apr 2013 17:46:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 31ED2C94C3; Fri, 26 Apr 2013 00:46:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366937211; bh=q8AbHoNzkpY8B/WFq4IuYcALZo+RIG7edwHBpgywEt0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=l5v6OGeR1/CE5T23YtnoPRtFC9V9m2vpaP77go7rB01k29h3dEEUPPkeoYFUB4RFG D0RcamSVe06+ZW2D6+QPkzxBwoypzOHh6eh2itSmCVwBeS1fR7HioSzPiF9Sbbxw1A cmwHeV5+Mte6nmQ0X78zwxOLYk83K9h0OVRe12Ng= 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; Fri, 26 Apr 2013 00:46:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 6EF2A216C47; Fri, 26 Apr 2013 00:46:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B5E1E32FAF70; Fri, 26 Apr 2013 10:46:32 +1000 (EST) To: "John R Levine" From: Mark Andrews References: In-reply-to: Your message of "25 Apr 2013 17:58:30 -0400." Date: Fri, 26 Apr 2013 10:46:32 +1000 Message-Id: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 00:46:53 -0000 In message , "John R Levine" writes: > >In my view, the issue relevant to DNSEXT ("moribund" or not) is the implication of the SPFBIS approach > >on the specification of new DNS RRtypes. I do not believe the issues faced in SPF deployment are unique > >and I imagine there will be protocols in the future that follow the same steps, i.e., put info in the > >DNS using TXT during initial experimental phases because it's easy/simple/doesn't require any > >approvals/documentation/interaction with others and then come back later and try to do "the right > >thing" when the protocol "works". > > Indeed. What could we do to encourage people to use new RRTYPEs from > the beginning of their experiments? The hardest thing is dealing with the naysayers. The entire BS that keeps getting repeated that getting a RR type is hard. It hasn't been hard for over a decade now. Well before SPF needed to make a decision about what type to use. There is a type range for experimenting. I used it for DLV experimentation then got a DLV type allocated and moved the code over to using it. This worked. Most of the delay was because the RFC Editor's expert reviewer didn't get back to me on the initial request being rejected. I then went AD sponsered and had to convince the IESG that it wasn't a run around of the dnsext wg which was about one additional email. DLV is a method of publishing a set of trust anchors which was expected to happen as far as DNSSEC was concerned. Working file: lib/dns/rdata/generic/dlv_65323.c revision 1.5 date: 2006-02-17 12:04:14 +1100; author: marka; state: dead; lines: +1 -1; 1985. [protocol] DLV has now been assigned a official type code of 32769. [RT #15807] ---------------------------- revision 1.4 date: 2004-03-18 13:58:04 +1100; author: marka; state: Exp; lines: +4 -4; branches: 1.4.18; 1.4.584; pullup silence compiler fixes ifconfig.sh for Solaris 9 README updates ---------------------------- revision 1.3 date: 2004-03-16 16:22:30 +1100; author: marka; state: Exp; lines: +8 -9; copyright ---------------------------- revision 1.2 date: 2004-03-10 13:19:56 +1100; author: marka; state: Exp; lines: +282 -0; branches: 1.2.2; 1589. [func] DNSSEC lookaside validation. enable-dnssec -> dnssec-enable ---------------------------- revision 1.1 date: 2004-02-20 17:35:47 +1100; author: marka; state: dead; branches: 1.1.2; file dlv_65323.c was initially added on branch rt10440. > Wagging fingers, insulting people, and asserting that there is no > barrier to installing new versions of software has a proven track > record of failure. Perhaps we could identify the actual bottlenecks > (if you've read my previous zillion messages you know what I have in > mind) and figure out how to fix them. Nobody is stating that there is no barrier. Just that the barriers are not as big as people keep stating they are. If your DNS hoster doesn't support a type in their web interface complain to them or move to someone who does. Generic support for new types is nearly a decade old now. If your IDS doesn't allow new types to come through get a new IDS because the existing one is broken. The expection of new types has been part of the DNS from day one. A IDS should be able to cope with new types. This is about consumers picking reasonable DNS products for their needs. This is about vendors that deal with DNS data doing the right thing with respect to new types. Yes, registrars are DNS vendors. So too are firewall vendors. There are a lot of DNS vendors on this list that don't do the right thing with respect to new DNS types. ISC has changed our policy for new types from the "next .0 release" to "next point release" which reminds me we need to back port HIP and URI to 9.6.x Mark > R's, > John > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Thu Apr 25 17:53:51 2013 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 AC9B521F9705; Thu, 25 Apr 2013 17:53:51 -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 QY0z0ULKOctn; Thu, 25 Apr 2013 17:53:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E385721F96E7; Thu, 25 Apr 2013 17:53:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3Q0raWQ014562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 17:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366937629; bh=cEkPrjj/QJwjlEeXN1KSY9P6aKUsTJ0HlockEcSNFfI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mbQe6Mbg2qFQRqb5tQXhj8XZgrhk4yNlotwvN/HXYIqKhsr7+QphSQVydSFG0nEnR kATvuwsPd+9blYlTPc9VYEoZl7rR4hkq8cCvkWfO6hQyk8bcwSqd2T2BX0Sd+0WhDK n8YBLth1eyT90noZPtTS51tRiUOb1cDaKxu1ZEGs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366937629; i=@elandsys.com; bh=cEkPrjj/QJwjlEeXN1KSY9P6aKUsTJ0HlockEcSNFfI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s/Xsu4JRyUKM6xlgWGS/8G6kkksxsGl6siN1wzNqInVGXAtHKqV9Dk/H1f8lCwwCm 1/EmlNFgXSoHkSMS8o9a1o2GotoDoo8jYY4ywERaezzL1qHc7f9OcYixEJ92fMstS5 y5w50z35bGXCpS3KW5t6Nx88+6Bp41FKnXwJt2Mg= Message-Id: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 17:22:25 -0700 To: Doug Barton From: S Moonesamy In-Reply-To: <5179BC32.8050205@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 00:53:52 -0000 Hi Doug, At 16:28 25-04-2013, Doug Barton wrote: >Yep, been there, done that. It was a bad decision then, and it's >still a bad decision now. I realize that it's incredibly unpopular >to bluntly call bad decisions "bad decisions," but not doing so >doesn't make them any less bad. And, to make matters worse, I am ok if anyone says that it a bad decision. The thread for the discussion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html >The argument in 6686 boils down to, "We made a series of bad >decisions, which have led to a bad result. We now want to codify >that bad result instead of cleaning up our mess." I don't agree with >that in principle, and I don't agree with that in regards to this >particular case. I was the document shepherd for RFC 6686. There wasn't any comments during the Last Call. >https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is >where the thread starts. There is another parallel thread an a >related topic around that same time. I read the messages on that thread around the time they were posted. >https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html I also read those messages. >The topic has been raised numerous times since day 1 of SPF, and the >DNS folk who have said "the SPF RRtype should be the first (if not >only) choice" have been consistently ignored. I have to respectfully mention that I read all the messages that were posted to the SPFBIS mailing list. I cannot take into consideration comments posted to ietf@ if they are not part of the Last Call. >But what if all of the previous discussion was wrong? Simply saying >"we have discussed this extensively" doesn't refute sound technical >arguments either. :) If all the previous discussions were wrong I hope that the future discussions will be right. :-) >While I didn't follow the spfbis group, I have followed SPF from the >time before it was You missed http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-) At 17:15 25-04-2013, Doug Barton wrote: >5. Some fairly persuasive technical arguments from Andrew Sullivan >that putting SPF records into your zone is a good idea. Particularly this: >https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html [snip] >#5 Is also a "reasoned technical argument," which was not only >ignored, but twisted on its ear by at least one list member. The SPFBIS WG Chairs are the persons making the determination for discussions within the working group. I happen to be one of the SPFBIS WG co-chairs and the other co-chair is Andrew Sullivan. I didn't ignore his comments. I didn't ask Andrew Sullivan whether he ignored his comments. If I misunderstood or misinterpreted his comments he would likely talk to me about that. That makes it unlikely that any twisting would reach my ears. :-) Regards, S. Moonesamy From dougb@dougbarton.us Thu Apr 25 18:30:47 2013 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 1698721F9731; Thu, 25 Apr 2013 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, 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-PC6vWVnWcv; Thu, 25 Apr 2013 18:30:46 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC321F9746; Thu, 25 Apr 2013 18:30:44 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id D771922BAA; Fri, 26 Apr 2013 01:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366939844; bh=U8WXo2UFoQyHjEDL+mg7IuRDArNSlCCCxqoXvER6ODE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=excMj+QuChGFY+nJmvYfWftJOCPGS1WJCVExrX92ElhmsZolirxuR/SlTZ44n6fu6 rI9OGSeJrbTnLXIsmBZzdDRPq03bYkUmEVS2brwgtfqLriFWO1KP5U5+UBxdbolMX+ +ZJql+CCbZse3AJo8obNhHUu5XlIwcFji99SYRMQ= Message-ID: <5179D8C3.8090207@dougbarton.us> Date: Thu, 25 Apr 2013 18:30:43 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> In-Reply-To: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 01:30:47 -0000 Note, I'm going to push back on some of the things you say below, but I don't want the main point I'm trying to make to get lost: 1. It's not too late to do the right thing, 2. So we should do that. Arguing about how we got here is fun and all, but not germane to the really important bit. On 04/25/2013 05:22 PM, S Moonesamy wrote: > Hi Doug, > At 16:28 25-04-2013, Doug Barton wrote: >> Yep, been there, done that. It was a bad decision then, and it's still >> a bad decision now. I realize that it's incredibly unpopular to >> bluntly call bad decisions "bad decisions," but not doing so doesn't >> make them any less bad. And, to make matters worse, > > I am ok if anyone says that it a bad decision. The thread for the > discussion started at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html > >> The argument in 6686 boils down to, "We made a series of bad >> decisions, which have led to a bad result. We now want to codify that >> bad result instead of cleaning up our mess." I don't agree with that >> in principle, and I don't agree with that in regards to this >> particular case. > > I was the document shepherd for RFC 6686. There wasn't any comments > during the Last Call. There are only so many times that people can say "this is a bad idea," then get ignored, and then have enthusiasm to come back and say the same thing again. I didn't follow the pre-publication of 6686, as I had other things to do at the time. However the volume of previous discussion over the last 8+ years should have been sufficient to render the idea of deprecating the SPF RRtype a non-starter. The fact that the draft got written in the first place said a lot about the chances of any objections being considered. >> https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is >> where the thread starts. There is another parallel thread an a related >> topic around that same time. > > I read the messages on that thread around the time they were posted. > >> https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html > > I also read those messages. > >> The topic has been raised numerous times since day 1 of SPF, and the >> DNS folk who have said "the SPF RRtype should be the first (if not >> only) choice" have been consistently ignored. > > I have to respectfully mention that I read all the messages that were > posted to the SPFBIS mailing list. I cannot take into consideration > comments posted to ietf@ if they are not part of the Last Call. I have to respectfully point out that a) there is a wider world beyond spfbis, and b) the reasoned technical arguments that were presented on the list (not to mention the running code) should have been sufficient to push the group in the direction of preferring the SPF RRtype with an eye toward deprecating TXT in the future. I don't know why, specifically, that didn't happen; but I also don't care. What I want to see happen is that we do the right thing now. >> But what if all of the previous discussion was wrong? Simply saying >> "we have discussed this extensively" doesn't refute sound technical >> arguments either. :) > > If all the previous discussions were wrong I hope that the future > discussions will be right. :-) Voila! :) >> While I didn't follow the spfbis group, I have followed SPF from the >> time before it was > > You missed > http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-) > > At 17:15 25-04-2013, Doug Barton wrote: >> 5. Some fairly persuasive technical arguments from Andrew Sullivan >> that putting SPF records into your zone is a good idea. Particularly >> this: >> https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html > > [snip] > >> #5 Is also a "reasoned technical argument," which was not only >> ignored, but twisted on its ear by at least one list member. > > The SPFBIS WG Chairs are the persons making the determination for > discussions within the working group. I happen to be one of the SPFBIS > WG co-chairs and the other co-chair is Andrew Sullivan. I didn't ignore > his comments. I didn't ask Andrew Sullivan whether he ignored his > comments. If I misunderstood or misinterpreted his comments he would > likely talk to me about that. That makes it unlikely that any twisting > would reach my ears. :-) It wasn't any of your messages I was referring to. Doug From johnl@taugh.com Thu Apr 25 18:32:52 2013 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 7DD8021F9746 for ; Thu, 25 Apr 2013 18:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Tu33S3E5nee8 for ; Thu, 25 Apr 2013 18:32:51 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8A94921F9743 for ; Thu, 25 Apr 2013 18:32:51 -0700 (PDT) Received: (qmail 44462 invoked from network); 26 Apr 2013 01:32:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=adac.5179d943.k1304; bh=d5vW+163E8hDIJRvET4xuhVLwns2DnxyX5PMrRl+bQ0=; b=jyJ3PQQVhNsYqcAxUyl42SBPOMWDrA3Ksz61/ttXYKsWGWzBeJ4AyPJ8fsbgBjEeuToFywjnW//ogNCcTJD6N87OoGvZVMMKvAboZ8jGyUQffIKQgAbbvcO7lcRgkeP+wAQYANG55Shv1Fjt8wnbxsPTTIkiYr3E3ISO6kiLenQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=adac.5179d943.k1304; bh=d5vW+163E8hDIJRvET4xuhVLwns2DnxyX5PMrRl+bQ0=; b=u0ky0AJHkGztCim428MwDRrq6jnf8b75QgEouCTSEO0tHnHt6kk7QiRTb/eloDmadrhSflx//ge4EieSMMmbo6mw8mzjoXo/zb6+ldhdagfe5nHflvCLREmDMyltQ6bBIeaDicT4peuNcXCwOafhw6iOZ7ataO3oFLXsTw9hzig= Received: (ofmipd 127.0.0.1); 26 Apr 2013 01:32:28 -0000 Date: 25 Apr 2013 21:32:50 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 01:32:52 -0000 > Nobody is stating that there is no barrier. Just that the barriers > are not as big as people keep stating they are. If your DNS hoster > doesn't support a type in their web interface complain to them or > move to someone who does. Generic support for new types is nearly > a decade old now. You must know a different set of DNS hosters than I do. It's vanishingly rare to find one that lets you insert random records via the provisioning software. You can go looking for ones you like, but good luck. For the vast majority of DNS users, it's a feature that they can't install random crud, not a bug. This is why I keep saying over and over again that it would be nice if we made it easier for them to handle new RRTYPEs in a way that makes it harder to shoot yourself in the foor than allowing random hex strings. R's, John From dougb@dougbarton.us Thu Apr 25 18:41:33 2013 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 168C821F976B for ; Thu, 25 Apr 2013 18:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 1Tzhk4bKyWAu for ; Thu, 25 Apr 2013 18:41:32 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E721F9769 for ; Thu, 25 Apr 2013 18:41:32 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 3E62C22BA8 for ; Fri, 26 Apr 2013 01:41:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366940492; bh=zoWwWSB15VCCdXW4Nm7NVGJAz4s92zltla6Xt/HSK7g=; h=Date:From:To:Subject:References:In-Reply-To; b=s450eVDqdbWnJz/yJQRliTxN5gtFDDWCIOq26pjjvKdq8XZqHvLVwZX4kr+Gu9kMz 9EM2lIkokvRAhgTHrFBY0nD+sIyenPbGfXbi9pqIl68U8MGzzlAdFayLwTaJxDOxS+ 73KYn2kEHprwofOlxQ4rVz28zHzuPEmMqS2Km7SE= Message-ID: <5179DB4B.2040403@dougbarton.us> Date: Thu, 25 Apr 2013 18:41:31 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 01:41:33 -0000 On 04/25/2013 06:32 PM, John R Levine wrote: >> Nobody is stating that there is no barrier. Just that the barriers >> are not as big as people keep stating they are. If your DNS hoster >> doesn't support a type in their web interface complain to them or >> move to someone who does. Generic support for new types is nearly >> a decade old now. > > You must know a different set of DNS hosters than I do. It's vanishingly > rare to find one that lets you insert random records via the provisioning > software. You can go looking for ones you like, but good luck. For the > vast majority of DNS users, it's a feature that they can't install random > crud, not a bug. > > This is why I keep saying over and over again that it would be nice if we > made it easier for them to handle new RRTYPEs in a way that makes it > harder to shoot yourself in the foor than allowing random hex strings. John, I realize that you have an agenda to push your idea, but for the sake of anyone new to this discussion who hasn't seen my response to this before: 1. Insert the ability into the interface to add freeform stuff 2. Run the equivalent of named-checkzone prior to committing the change 3. Profit! Fixing the provisioning systems isn't hard to do, it's not even a complex problem. The issue is that for the most part service providers don't want to make ANY changes to existing stuff because it eats into their profits. That's understandable, but if we're going to give in to that then the answer is "no new RRtypes ever," which is not acceptable. So can we please stop trotting out the provisioning system argument? Mark is right, new RRtypes aren't hard to deal with. I've made the point previously that things like DNSSEC and AAAA have long-since "cracked the ice" on the old "fire and forget" method of DNS software deployment, and every day that goes by brings new and exciting developments in the DNS world. That doesn't mean that deploying new stuff is "easy," just that it's a lot easier than it used to be, gets easier every day, and there is market pressure to keep making it get easier as we go along. Doug From marka@isc.org Thu Apr 25 19:16:10 2013 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 F066E21F975F for ; Thu, 25 Apr 2013 19:16:10 -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 FPzpULdlb69q for ; Thu, 25 Apr 2013 19:16:10 -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 AFBDA21F9761 for ; Thu, 25 Apr 2013 19:16:09 -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 50E005F9949; Fri, 26 Apr 2013 02:15:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366942569; bh=tPdgPC5JXAYkbxd8hnXAmumMtC4EoyhxOovNv+Xxlx4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=GfIYeevjXFrWQx8X9Im6wUeD2EgzMKojxfR5MRDH8QTOapPfV+mYQrC4DbLT5v83e mAk+hyBy2hDBfmQwGJ05nXp8ExpNnoxALodpF5dgeAsYgq60BzI8y8hzhbmZJ4VtyB 12voykcli/hooOlTXu7pmzgNMabPtkvpE01JOP7Y= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (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 66CAA216C43; Fri, 26 Apr 2013 02:15:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 06E2632FBABE; Fri, 26 Apr 2013 12:15:29 +1000 (EST) To: Doug Barton From: Mark Andrews References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <5179DB4B.2040403@dougbarton.us> In-reply-to: Your message of "Thu, 25 Apr 2013 18:41:31 -0700." <5179DB4B.2040403@dougbarton.us> Date: Fri, 26 Apr 2013 12:15:29 +1000 Message-Id: <20130426021530.06E2632FBABE@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 02:16:11 -0000 In message <5179DB4B.2040403@dougbarton.us>, Doug Barton writes: > On 04/25/2013 06:32 PM, John R Levine wrote: > >> Nobody is stating that there is no barrier. Just that the barriers > >> are not as big as people keep stating they are. If your DNS hoster > >> doesn't support a type in their web interface complain to them or > >> move to someone who does. Generic support for new types is nearly > >> a decade old now. > > > > You must know a different set of DNS hosters than I do. It's vanishingly > > rare to find one that lets you insert random records via the provisioning > > software. You can go looking for ones you like, but good luck. For the > > vast majority of DNS users, it's a feature that they can't install random > > crud, not a bug. > > > > This is why I keep saying over and over again that it would be nice if we > > made it easier for them to handle new RRTYPEs in a way that makes it > > harder to shoot yourself in the foor than allowing random hex strings. > > John, > > I realize that you have an agenda to push your idea, but for the sake of > anyone new to this discussion who hasn't seen my response to this before: > > 1. Insert the ability into the interface to add freeform stuff > 2. Run the equivalent of named-checkzone prior to committing the change > 3. Profit! And it's not like example code to do this for individual RRs doesn't exist. It would be about 10 minutes work to take this existing test code and make it into a application that returns 0 or 1 for the exit code. It would still need a man page, test suite for the application itself to be written, etc. but overall not a big deal. One could even make it spit out the records in unknown format if you were worried about having to upgrade the nameserver quickly. [drugs:bind9.drugs/bin/tests] marka% ./rdata_test IN A 1.2.3.4 dns_rdatatype_fromtext returned unknown class/type(65543) [drugs:bind9.drugs/bin/tests] marka% ./rdata_test A IN 1.2.3.4 type = A(1) class = IN(1) "1.2.3.4" [drugs:bind9.drugs/bin/tests] marka% ./rdata_test A IN 1.2.3.4.5 type = A(1) class = IN(1) dns_rdata_fromtext: stream-0x7fff7bf21a90:1: near '1.2.3.4.5': bad dotted quad dns_rdata_fromtext returned bad dotted quad(65541) [drugs:bind9.drugs/bin/tests] marka% > Fixing the provisioning systems isn't hard to do, it's not even a > complex problem. The issue is that for the most part service providers > don't want to make ANY changes to existing stuff because it eats into > their profits. That's understandable, but if we're going to give in to > that then the answer is "no new RRtypes ever," which is not acceptable. > > So can we please stop trotting out the provisioning system argument? > Mark is right, new RRtypes aren't hard to deal with. I've made the point > previously that things like DNSSEC and AAAA have long-since "cracked the > ice" on the old "fire and forget" method of DNS software deployment, and > every day that goes by brings new and exciting developments in the DNS > world. That doesn't mean that deploying new stuff is "easy," just that > it's a lot easier than it used to be, gets easier every day, and there > is market pressure to keep making it get easier as we go along. > > Doug > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Thu Apr 25 20:29:16 2013 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 AAFD121F9199; Thu, 25 Apr 2013 20:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 r3ukD6dX7rIj; Thu, 25 Apr 2013 20:29:16 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 640F721F9080; Thu, 25 Apr 2013 20:29:15 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id z53so3317417wey.9 for ; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iCqwh+C9cFLLdVHFJpgFaPdNl1odqxj5zSBSviuQOAM=; b=aZ8Xs7PHzGWKoLka+oEFPW8FtPn7LOKZALTmqNdZOylb06pCp14fEPicVIkhmkSiWf ImEyv4b0lSRiZPVGdcpNAWgV5cmuHAJtUYbFDzHwmhQ6gowfBCAQj90m6KUQVwkm6kBH tM9FMDM0OmCVU1FMqlk5zO6dqAtFM7qvB0bQwcKblkLELSh6dR9zakiqj0DR5FXyQOIV SZYh00wb9LqzLy1n0LLeE7aTAhUS6rgalJPQfNdU5gkCaYO3kqV/b83IiyQjvoPjMmsr FaNQZg66VagoMnVrZr3hX/eARrxr+6WkPLVH2EcqsFKBmDnCXWlvpx2YZbWlRSEgdYtm VhXw== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr32118170wjb.17.1366946954561; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) In-Reply-To: <5179BC32.8050205@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> Date: Thu, 25 Apr 2013 20:29:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=047d7b5d8cffa74d6e04db3b2359 Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 03:29:16 -0000 --047d7b5d8cffa74d6e04db3b2359 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > Yep, been there, done that. It was a bad decision then, and it's still a > bad decision now. I realize that it's incredibly unpopular to bluntly call > bad decisions "bad decisions," but not doing so doesn't make them any less > bad. And, to make matters worse, not doing so has led to a non-trivial > number of those bad decisions becoming de facto standards. This has at > least 2 very bad side effects ... first, we have to live with the bad de > facto standards; but more importantly we are providing encouragement to > people who wish to make similar bad decisions down the road. > > The argument in 6686 boils down to, "We made a series of bad decisions, > which have led to a bad result. We now want to codify that bad result > instead of cleaning up our mess." I don't agree with that in principle, and > I don't agree with that in regards to this particular case. > > Further, while cleaning up the SPF mess would require nothing more than a > marginal amount of extra work now, plus the passage of time, there is no > reason not to actually clean up the mess. I think this continues to trivialize exactly what it means to migrate the enormous deployed base of SPF in the manner you're pushing. I fully agree with your premise that it should've been "done right" in the beginning and I lament that it was not, but I don't agree that fixing this now is worth moving a mountain, especially when I don't believe the people saying that here will be among the people doing even a fraction of the moving. At least half of the reason we landed here is because of an environment that was basically hostile to doing it right in the first place. The rules for getting new RRtypes have been improved -- I think we all agree on that -- but, as you already conceded, there's still a large deployed base of faulty firewalls and DNS tools out there that don't exactly make use of uncommon RRtypes easy. So how much energy are the DNS experts going to put into cleaning up their house while demanding the mail people clean up theirs? I would even go so far as to say that the DNS part has to happen first, before any cleanup on the email side is practical to consider. The deployed SPF base probably won't give a damn if the IETF suddenly releases an RFC that exclaims "Everybody migrate to type 99!" From the perspective of large and small operators around the world, what's out there is working now, and messing with it is asking for pain; engineers' time to switch and debug costs a lot of money, so they have no incentive whatsoever to comply with a proposed change to "fix" a service that is philosophically broken but operationally just fine. Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows this path again. -MSK --047d7b5d8cffa74d6e04db3b2359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton <dougb@dou= gbarton.us> wrote:
Yep, been there, done that. It was a bad dec= ision then, and it's still a bad decision now. I realize that it's = incredibly unpopular to bluntly call bad decisions "bad decisions,&quo= t; but not doing so doesn't make them any less bad. And, to make matter= s worse, not doing so has led to a non-trivial number of those bad decision= s becoming de facto standards. This has at least 2 very bad side effects ..= . first, we have to live with the bad de facto standards; but more importan= tly we are providing encouragement to people who wish to make similar bad d= ecisions down the road.

The argument in 6686 boils down to, "We made a series of bad decisions= , which have led to a bad result. We now want to codify that bad result ins= tead of cleaning up our mess." I don't agree with that in principl= e, and I don't agree with that in regards to this particular case.

Further, while cleaning up the SPF mess would require nothing more than a m= arginal amount of extra work now, plus the passage of time, there is no rea= son not to actually clean up the mess.

I think this continues to trivialize exactly what it means to migrate the e= normous deployed base of SPF in the manner you're pushing. I fully agre= e with your premise that it should've been "done right" in th= e beginning and I lament that it was not, but I don't agree that fixing= this now is worth moving a mountain, especially when I don't believe t= he people saying that here will be among the people doing even a fraction o= f the moving.

At least half of the reason we landed here is because of an = environment that was basically hostile to doing it right in the first place= .=A0 The rules for getting new RRtypes have been improved -- I think we all= agree on that -- but, as you already conceded, there's still a large d= eployed base of faulty firewalls and DNS tools out there that don't exa= ctly make use of uncommon RRtypes easy.=A0 So how much energy are the DNS e= xperts going to put into cleaning up their house while demanding the mail p= eople clean up theirs?=A0 I would even go so far as to say that the DNS par= t has to happen first, before any cleanup on the email side is practical to= consider.

The deployed SPF base probably won't give a damn if the = IETF suddenly releases an RFC that exclaims "Everybody migrate to type= 99!"=A0 From the perspective of large and small operators around the = world, what's out there is working now, and messing with it is asking f= or pain; engineers' time to switch and debug costs a lot of money, so t= hey have no incentive whatsoever to comply with a proposed change to "= fix" a service that is philosophically broken but operationally just f= ine.

Thus, I maintain that we take our licks on this one and just= take steps to ensure that nobody follows this path again.

-MSK
--047d7b5d8cffa74d6e04db3b2359-- From johnl@iecc.com Thu Apr 25 20:43:49 2013 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 3A25521E803F for ; Thu, 25 Apr 2013 20:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.9 X-Spam-Level: X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 TqTtFBraqVwN for ; Thu, 25 Apr 2013 20:43:48 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A69921E8048 for ; Thu, 25 Apr 2013 20:43:46 -0700 (PDT) Received: (qmail 68596 invoked from network); 26 Apr 2013 03:43:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2013 03:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5179f7ef.xn--9vv.k1304; i=johnl@user.iecc.com; bh=uu7vNzTJdjNINTG409DBBQTHjlIB9gK4CcsPV8Cn9TE=; b=RZuH2W0otbYQ44ZBMJxlY5xIMq7B0+LyHJTwx08EekBzi/JV2nGlITlqERLx4l7bmgWHGsz54iCqze3m4PYcaWg8hFP5dWds+e82oTnovV8/Nk4mQx3EtCjSZpAb37n1lYRESO1df1LN8VfXS/QZCMChMCYDPM1G3WPcfrnrU/Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5179f7ef.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=uu7vNzTJdjNINTG409DBBQTHjlIB9gK4CcsPV8Cn9TE=; b=WTVBwoRwUdZWHebR9L6z8cw2sQ/BFBHIljW06Z6a5YCa7fpYYM3wvHNISfQkKQbycfpTZzTHWtirVQHblIfO2nweOGPhzhhrhtlXHMtrQu8nr0fVaojYXV0Y/PFzgDft8EVBh592LvFzumiCfiaWQuG/YeWNGLVWvwEw3uhHI5M= Date: 26 Apr 2013 03:43:21 -0000 Message-ID: <20130426034321.68173.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <5179DB4B.2040403@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 03:43:49 -0000 >> 1. Insert the ability into the interface to add freeform stuff >> 2. Run the equivalent of named-checkzone prior to committing the change >> 3. Profit! I don't know whether to laugh or cry. No, this won't work with provisioning systems in the real world, that have to be usable by people who are not DNS weenies, and work in systems where the software upgrade cycle is months or years, not days. There are real reasons that seven years after RFC 4408, most provisioning systems still don't handle type 99 records, and it's not because everyone who does e-mail is stupid. No need to respond, you've made your point, although it may not be what you thought it was. R's, John From marka@isc.org Thu Apr 25 21:11:51 2013 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 2641521E803F for ; Thu, 25 Apr 2013 21:11:51 -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 y348hgfd+uoe for ; Thu, 25 Apr 2013 21:11:50 -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 5D6C721F96A3 for ; Thu, 25 Apr 2013 21:11:50 -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 DEAF95F9863; Fri, 26 Apr 2013 04:11:41 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366949509; bh=Pw/Td3rpOINsJB4942+NEEhBM0rxRih7E1whr11S7S0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BwVE9nDEp9rz2S+3OhHxsJ5lyda5b4D58jtPMVF/Syx7H11IGHMr158pNN609zngK frr5MOnKcM/v76ftRvGfCACKt86czZ4PrxtuJCQtU86h/l7AHTPjW2nQWG8xHeWVcV PEuhbg+R7DdjGRXSeYtAy8OpazIRMvR24ZyDYdQE= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (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 06A0C216C40; Fri, 26 Apr 2013 04:11:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D7D7C32FE54F; Fri, 26 Apr 2013 14:11:32 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130426034321.68173.qmail@joyce.lan> In-reply-to: Your message of "26 Apr 2013 03:43:21 +0000." <20130426034321.68173.qmail@joyce.lan> Date: Fri, 26 Apr 2013 14:11:32 +1000 Message-Id: <20130426041132.D7D7C32FE54F@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 04:11:51 -0000 In message <20130426034321.68173.qmail@joyce.lan>, "John Levine" writes: > >> 1. Insert the ability into the interface to add freeform stuff > >> 2. Run the equivalent of named-checkzone prior to committing the change > >> 3. Profit! > > I don't know whether to laugh or cry. > > No, this won't work with provisioning systems in the real world, that > have to be usable by people who are not DNS weenies, and work in > systems where the software upgrade cycle is months or years, not days. > > There are real reasons that seven years after RFC 4408, most > provisioning systems still don't handle type 99 records, and it's not > because everyone who does e-mail is stupid. It just money. Really that is the only reason at this point. They won't spend a cent to make their systems updatable or they want to charge extra for supporting type 99 records. > No need to respond, you've made your point, although it may not be > what you thought it was. One can upgrade components of a system. Nameservers are regularly upgraded independently on the rest of the system. Similarly other tools are regularly upgraded. > R's, > John > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Thu Apr 25 21:23:09 2013 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 F152621E8048 for ; Thu, 25 Apr 2013 21:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] 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 ZopkHDd8H95E for ; Thu, 25 Apr 2013 21:23:05 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED0F21E8045 for ; Thu, 25 Apr 2013 21:23:05 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id A4A2D22B11; Fri, 26 Apr 2013 04:23:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366950184; bh=PuVh6Zp98vkeNGSrnwghrSFpkuvdn/FJIiPAfKXsjcY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fx7bdb5E/wZd5RIkVO6V2Pxx1cDaeKV6tR+el7a7bYIQUoMkN5uk+h/3QfnNoL/dv Csy+9WiuHWaobKhb6apbHhuMt1uJ6yqDJ3sL8jihCGepe/Z6UIC/C5rgt17pr45fhT +h8pFejDAvWPk2ODaTG25q74FvaHlYPFJhGNFf9A= Message-ID: <517A0127.4080806@dougbarton.us> Date: Thu, 25 Apr 2013 21:23:03 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Levine References: <20130426034321.68173.qmail@joyce.lan> In-Reply-To: <20130426034321.68173.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 04:23:09 -0000 On 04/25/2013 08:43 PM, John Levine wrote: >>> 1. Insert the ability into the interface to add freeform stuff >>> 2. Run the equivalent of named-checkzone prior to committing the change >>> 3. Profit! > > I don't know whether to laugh or cry. > > No, this won't work with provisioning systems in the real world, that > have to be usable by people who are not DNS weenies, and work in > systems where the software upgrade cycle is months or years, not days. Once again, I know that you want to promote your solution for this problem. That's fine, but that doesn't mean that it's the only solution, or even the best one. What I proposed would work "forever." There is no doubt that it requires more DNS knowledge, but most non-experts entering "special" or "custom" DNS are doing cut and paste anyway. > There are real reasons that seven years after RFC 4408, most > provisioning systems still don't handle type 99 records, and it's not > because everyone who does e-mail is stupid. Um, that's pretty much non-sequitur. > No need to respond, you've made your point, although it may not be > what you thought it was. Yep, a lot of that going around. :) Doug From doug.mtview@gmail.com Thu Apr 25 21:58:18 2013 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 D205A21F86D9 for ; Thu, 25 Apr 2013 21:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmEOSScbo6hG for ; Thu, 25 Apr 2013 21:58:18 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id D177721F8546 for ; Thu, 25 Apr 2013 21:58:17 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id c50so1191415eek.14 for ; Thu, 25 Apr 2013 21:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=vEQ0z1B0togGqDrRKUNUgNaZdVGztCvW7+kfLwO9b+o=; b=Uw9hlAJ4u6Io/ChrZbwIvvDr5ie38fP73ysDjymBc/kDUQBoRy9B0wDJUOX2AIsBmK QggyqTI5iic++rH7R3fiO1tRF/cb63uSeZiuiBB38/3KDFneWj6q2PtPgEM9tx0ktrgj fS6I/m/KtuRolTFtgMsSfEWdFiYqa+w+USpiSIWpSvV8psO0yuA6ae9A9thFw32HQmPc ZliamO1T0AwepDA/7S/eNvu+wTpxucmtCmKiyK9ZZ1kDPe1IlkofqNO6rGSaMOkf9UhX NATH9wRkCyL2AURqrUea2ERW6cBOWNcaE1bRvgq0BE5MyP9ju29GQelwmqYHVfVVuL08 wkPg== X-Received: by 10.14.104.6 with SMTP id h6mr38592170eeg.5.1366952297047; Thu, 25 Apr 2013 21:58:17 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id j43sm13870494eep.4.2013.04.25.21.58.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 21:58:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <517A0127.4080806@dougbarton.us> Date: Thu, 25 Apr 2013 21:58:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <853014EA-E5C6-429B-AEF4-A6E794FE688E@gmail.com> References: <20130426034321.68173.qmail@joyce.lan> <517A0127.4080806@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 04:58:19 -0000 On Apr 25, 2013, at 9:23 PM, Doug Barton wrote: > On 04/25/2013 08:43 PM, John Levine wrote: >>>> 1. Insert the ability into the interface to add freeform stuff >>>> 2. Run the equivalent of named-checkzone prior to committing the = change >>>> 3. Profit! >>=20 >> I don't know whether to laugh or cry. >>=20 >> No, this won't work with provisioning systems in the real world, that >> have to be usable by people who are not DNS weenies, and work in >> systems where the software upgrade cycle is months or years, not = days. >=20 > Once again, I know that you want to promote your solution for this = problem. That's fine, but that doesn't mean that it's the only solution, = or even the best one. What I proposed would work "forever." There is no = doubt that it requires more DNS knowledge, but most non-experts entering = "special" or "custom" DNS are doing cut and paste anyway. Doug, To be fair, a significant barrier was the Windows corporate environment = translating DNS to RPC with a limited template set. As it turns out, = use of the SPF protocol at the MUA is fairly limited. While overlaying = TXT RR is bad, these also offer policy for any domain or subdomain. = Some may simply wildcard TXT records and create problems for other = protocols using these records. One of the original motivations for = overlaying TXT was to permit wildcard use. IMHO, the high overhead associated with the SPF scheme as IPv6 is = deployed seems to ensure a more scalable and safer cryptograph scheme is = a likely replacement using standard RRs. Nothing needed for IPv6 is = really being solved using SPF or DKIM. Currently DKIM is easily spoofed = just as Hector demonstrated many years ago. Few providers are willing = to discard based upon SPF failures, but limit use to vetting NDNs. Many = providers unwilling to run macro expansions should have cause this = dangerous scheme to have been discarded long before the type 99 resource = allocation based upon the same sort of justifications.=20 Regards, Douglas Otis From drc@virtualized.org Thu Apr 25 22:40:02 2013 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 DB53821F97BE for ; Thu, 25 Apr 2013 22:40:02 -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 iyDLRDnnI85H for ; Thu, 25 Apr 2013 22:40:02 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 32ECB21F975F for ; Thu, 25 Apr 2013 22:40:01 -0700 (PDT) Received: from [10.0.1.2] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 8603C17166; Fri, 26 Apr 2013 05:40:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Fri, 26 Apr 2013 00:39:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1558C7-D0BF-4D80-B87D-D9164219B28E@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> To: John R Levine X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 05:40:03 -0000 John, On Apr 25, 2013, at 9:44 AM, John R Levine wrote: > The much more serious reason is that the provisioning systems to let = system managers install type 99 records into their DNS did not exist, = and for the most part still do not exist. =20 Standard chicken-or-egg problem endemic to trying to deploy anything = new. I actually find this situation a bit amusing. Not being a follower of = these things, I actually honestly didn't know that TXT RRs was the = preferred method to do SPF when I set up SPF on my server about a year = ago. The user interface I was using (CloudFlare) supported SPF and it = actually didn't occur to me to use TXT. It wasn't until an unrelated = problem showed up that someone who follows the IETF SPF stuff laughed at = me and said I should be using TXT RRs instead of SPF RRs. =20 > I know a lot of the people who did early SPF installations and they = uniformly reported that even getting the provisioning software to = support TXT records that have been around since the dawn of the DNS was = painful, and there would have been no hope for a new and exotic record = type. Since their goal was to make SPF actually work, they used a = kludge. It's the same reason DKIM uses TXT records. So I believe the question here isn't really related to the horrible = bogosities of the past (that I think we can all cite evidence for) but = what should be the future. I'm reminded of the (perhaps apocryphal) = story of the guy who wrote make(1) deciding that having whitespace = significant in Makefiles was a mistake, but the installed base was too = large to fix it -- the installed base at the time being 20 developers.=20= I guess it depends on what the view of the future of SPF actually is. = If the assumption is that SPF is at or near its peak and SPF usage will = dwindle over time, then it doesn't actually matter whether TXT or SPF = RRs are used. However, if the assumption is that SPF will see increased = deployment over time, eventually dwarfing the number of deployments = currently, then I personally believe the approach proposed in the SPFBIS = draft is simply broken. IMHO, YMMV.=20 Not being tuned in to the world in which SPF matters all that much (as = evidenced by my apparently silly use of the SPF RR), I have no idea what = the assumptions are regarding future use of SPF. >>> Yes, the ossification of the DNS makes introducing new things = challenging however as Mark pointed out, software was beginning to do = the right thing and there actually are web interfaces out there that let = folks enter SPF records (I use one). > Wow, and it's only taken eight fripping years. Perhaps if we wait = another century the provisioning systems will catch up. =20 As I said, standard chicken-or-egg. Why should a provisioning system = bother implementing anything other than TXT if no one is asking for = anything other than TXT? Why should anyone ask for their provisioning = system to support anything other than TXT since using TXT appears to = work? Of course, using TXT has all sorts of downsides, but few if any of those = are apparent the the person who puts TXT into their DNS editor. The = fact that folks are implementing SPF RR support now (as evidenced by = Mark's comments and my experiences) might suggest that the migration = curve is trending in the right direction and the SPFBIS decision might = have been wrong. > If the DNS crowd spent half the effort addressing the provisioning = problem that you do trying to deny that it exists, it'd have been fixed = years ago. My dnsextlang proposal is one approach, but surely not the = only one. Sorry, when folks can't figure out how to implement an editor that by = definition is identical to the editor used for the TXT RR, I have a bit = of skepticism that they'll implement anything like dnsextlang. However, = with that said, I fully support moving forward with dnsextlang. > PS: The system that lets you enter SPF records wouldn't be Godaddy, = would it? Nope. CloudFlare. Regards, -drc From drc@virtualized.org Thu Apr 25 23:05:23 2013 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 8987A21F97C7; Thu, 25 Apr 2013 23:05:23 -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 2Quedfh9U5ke; Thu, 25 Apr 2013 23:05:23 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BD21F97AF; Thu, 25 Apr 2013 23:05:23 -0700 (PDT) Received: from [10.0.1.2] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B944E17166; Fri, 26 Apr 2013 06:05:22 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Fri, 26 Apr 2013 01:05:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:05:23 -0000 Murray, On Apr 25, 2013, at 10:29 PM, "Murray S. Kucherawy" = wrote: > I think this continues to trivialize exactly what it means to migrate = the enormous deployed base of SPF in the manner you're pushing. Out of curiosity, what do folks who follow SPF think the current = "enormous deployed base" is compared to the future deployed base? > At least half of the reason we landed here is because of an = environment that was basically hostile to doing it right in the first = place.=20 Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF = community a good lesson. (Seriously?) > So how much energy are the DNS experts going to put into cleaning up = their house while demanding the mail people clean up theirs?=20 So, this is about revenge because it used to be hard to get RRtypes?=20 > The deployed SPF base probably won't give a damn if the IETF suddenly = releases an RFC that exclaims "Everybody migrate to type 99!"=20 Yep. This gets into projections about the future. If SPF has topped = out, it simply doesn't matter. If SPF is going to continue to grow, = then it probably does matter. > =46rom the perspective of large and small operators around the world, = what's out there is working now, and messing with it is asking for pain; = engineers' time to switch and debug costs a lot of money, so they have = no incentive whatsoever to comply with a proposed change to "fix" a = service that is philosophically broken but operationally just fine. The point is that it isn't just fine. It does have operational impacts, = from potentially increased fragmentation/fallback to TCP to increased = complexity in TXT RR parsers that have to distinguish between the myriad = of crap that's residing at the zone apex TXT RR, etc. Of course, most = of these negative impacts are hidden to the folks who are putting the = TXT RRs in the zone, so it's all good, right? > Thus, I maintain that we take our licks on this one and just take = steps to ensure that nobody follows this path again. And how do you propose that exactly, particularly given the precedent = set by SPFBIS? Regards, -drc From envite@rolamasao.org Thu Apr 25 23:22:11 2013 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 D564921F97D9 for ; Thu, 25 Apr 2013 23:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9zkUXzFhEr8 for ; Thu, 25 Apr 2013 23:22:11 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7921F97C8 for ; Thu, 25 Apr 2013 23:22:10 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 98D6811EAB for ; Fri, 26 Apr 2013 07:22:08 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Fri, 26 Apr 2013 07:21:49 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <20130425013317.36729.qmail@joyce.lan> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515B696@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2247587.asWfxkstv3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201304260722.01926.envite@rolamasao.org> Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:22:12 -0000 --nextPart2247587.asWfxkstv3 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jueves, 25 de abril de 2013 12:13:29 Ted Lemon wrote: > On Apr 25, 2013, at 12:37 AM, David Conrad wrote: > > I have no illusions that I'd be able to sway anyone related to spfbis -- > > minds appear to be quite made up based on the private messages I've > > received >=20 > Then perhaps we should all tromp on this in IETF last call. I certainly > agree with your take on this: the idea that a document would advocate the > use of a TXT record because promulgating SPF records is "too hard" is just > broken. >=20 I agree with this. Tha main idea with TXT records is to keep data aimed to= =20 humans, not to machines. In fac, a machine should never request a TXT Query= on=20 its own. Regards Noel er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart2247587.asWfxkstv3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlF6HQkACgkQcLQA8+7Hw3Ls0wCdFrS32dLaygHv7LUem8s9Mk3Z qrsAn1zc9Sxkqg/W08hJIeUw1v4+8xNn =s47/ -----END PGP SIGNATURE----- --nextPart2247587.asWfxkstv3-- From jim@rfc1035.com Thu Apr 25 23:22:37 2013 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 AEA8821F97E5 for ; Thu, 25 Apr 2013 23:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=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 gIvYmVjU8Zl1 for ; Thu, 25 Apr 2013 23:22:37 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5E621F97E0 for ; Thu, 25 Apr 2013 23:22:37 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 1CCD3CBC420; Fri, 26 Apr 2013 07:22:36 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 07:22:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 06:22:37 -0000 On 26 Apr 2013, at 01:46, Mark Andrews wrote: > The hardest thing is dealing with the naysayers. The entire BS > that keeps getting repeated that getting a RR type is hard. It's not BS. Getting new RRtypes is easier than it used to be (in = principle) but it is not easy. Or at least, this WG creates the = perception that it is not easy. Witness the recent pushback and BS = around Joe's EUI{48,64} RRtypes. BWT, this was AFTER the RRtype = Allocation Policy of RFC6895 had been followed and IANA had issued the = type codes. That resistance from this WG -- "I'm in favour of = liberalising type code assignments, but..." -- was not an isolated = event. It's disappointing but not surprising if others take the path of least = resistance and go with a TXT record and avoid the hassle of the RFC6895 = template and expert review. Not because that process is defective, but = because the BS that tends to surface on this list. Having been on the = receiving end of that treatment, I would think long and hard about = coming to the IETF with a request for a new RRtype code instead of doing = the "wrong" thing by following the herd and overloading the TXT record. = Or just plucking a number from the reserved for private use range and = hoping nobody else picks the same one. From marka@isc.org Thu Apr 25 23:30:15 2013 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 5DEC721F96FD for ; Thu, 25 Apr 2013 23:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.384, 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 zqUvoL2OURVp for ; Thu, 25 Apr 2013 23:30:14 -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 9F4AA21F91A2 for ; Thu, 25 Apr 2013 23:30:14 -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 7232D5F98B6; Fri, 26 Apr 2013 06:30:04 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366957813; bh=IeN+Z/aLuFoE9fkhHvcBehCtW36bX8VfHabunOjMf7o=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=aE+xIWPkuYL3a06Pcp18h3Xha6ekjiSCJoqlxL8HhdLDGXtnI0dXlpe9Ko4iY1ygg epxkNwlXt0xGNp/tYg2nxQynzGjvDXMd7DXZ+aw3apmMs0GOAPn5/9niqAZJ3MOx5K bs54yJmvby0FOOGbRhYLuY/gNwe5qUmyZCPLNy2E= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (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 C930E216C47; Fri, 26 Apr 2013 06:30:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0A9A13303183; Fri, 26 Apr 2013 16:30:00 +1000 (EST) To: Jim Reid From: Mark Andrews References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> In-reply-to: Your message of "Fri, 26 Apr 2013 07:22:35 +0100." <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> Date: Fri, 26 Apr 2013 16:29:59 +1000 Message-Id: <20130426063000.0A9A13303183@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 06:30:15 -0000 In message <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com>, Jim Reid writes: > On 26 Apr 2013, at 01:46, Mark Andrews wrote: > > > The hardest thing is dealing with the naysayers. The entire BS > > that keeps getting repeated that getting a RR type is hard. > > It's not BS. Getting new RRtypes is easier than it used to be (in > principle) but it is not easy. Or at least, this WG creates the > perception that it is not easy. Witness the recent pushback and BS around > Joe's EUI{48,64} RRtypes. BWT, this was AFTER the RRtype Allocation > Policy of RFC6895 had been followed and IANA had issued the type codes. > That resistance from this WG -- "I'm in favour of liberalising type code > assignments, but..." -- was not an isolated event. The type code is allocated. Code supporting EUI48 and EUI64 has shipped. BIND 9.6, 9.8 and 9.9 all support EUI48 and EUI64. The rest is bikeshedding. > It's disappointing but not surprising if others take the path of least > resistance and go with a TXT record and avoid the hassle of the RFC6895 > template and expert review. Not because that process is defective, but > because the BS that tends to surface on this list. Having been on the > receiving end of that treatment, I would think long and hard about coming > to the IETF with a request for a new RRtype code instead of doing the > "wrong" thing by following the herd and overloading the TXT record. Or > just plucking a number from the reserved for private use range and hoping > nobody else picks the same one. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Thu Apr 25 23:30:16 2013 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 11AB621F91A2; Thu, 25 Apr 2013 23:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JxMwzbcy2enj; Thu, 25 Apr 2013 23:30:15 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C854C21F91B7; Thu, 25 Apr 2013 23:30:14 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm14so213877wib.5 for ; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qkKxxbS61c+29IzFzh2ux1pgevJn908JuLVXQ7A2hXg=; b=MbUqrqf1wE9/nNlZ08qaiyjcKrz1Ndwz0Qr8hZ2dmQcRG+5IbUl1IWQEAkqTw4xWbD u5kBnRR8RIqoQ2U91XUEeXyJtKz9V4Z7Eobj/P6knOSTO2aQ4vOKC0hrSIwK2pDRQ4Xe OQdysmlAvMPJHktVyNF+oQm+GcyR75jluMFcp5+fv9MjpeZoYp/SsOoxn+nKD2dC0Bio lYjqjZFAAtLApnHZvkiL75CiXl0TWGaExJJKhDT6SSfSebTnzN0W74T6k3ouagymeJAc vMtFGNknpP4QG4XRjCb1NW0NxA5bxdMFgSbogGhHY0bpQd+5Vomxvyb7eZld6K+AQkIB /m+A== MIME-Version: 1.0 X-Received: by 10.180.37.101 with SMTP id x5mr2317657wij.0.1366957813404; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) In-Reply-To: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> Date: Thu, 25 Apr 2013 23:30:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: David Conrad Content-Type: multipart/alternative; boundary=e89a8f646ff3e4184a04db3daa27 Cc: "spfbis@ietf.org" , "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:30:16 -0000 --e89a8f646ff3e4184a04db3daa27 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 11:05 PM, David Conrad wrote: > > So how much energy are the DNS experts going to put into cleaning up > their house while demanding the mail people clean up theirs? > > So, this is about revenge because it used to be hard to get RRtypes? > Did I really come across as that petty? No, what I'm saying is that the way things were ten years ago pushed the SPF community to the place it's in now, ugly as it is. SPF, in the interim, has become very widely deployed. Suddenly now we have a few voices from the ivory tower asserting that the same community needs to go out and re-do things the way they should have been done in the first place, now that we finally have a somewhat more reasonable perspective, even though some of the vestiges of ten years ago are in fact still around. My reaction to that is "You can't be serious." That doesn't sound like revenge at all to me, just pragmatism. > > The deployed SPF base probably won't give a damn if the IETF suddenly > releases an RFC that exclaims "Everybody migrate to type 99!" > > Yep. This gets into projections about the future. If SPF has topped out, > it simply doesn't matter. If SPF is going to continue to grow, then it > probably does matter. > I think it's much closer to the former. > The point is that it isn't just fine. It does have operational impacts, > from potentially increased fragmentation/fallback to TCP to increased > complexity in TXT RR parsers that have to distinguish between the myriad of > crap that's residing at the zone apex TXT RR, etc. Of course, most of > these negative impacts are hidden to the folks who are putting the TXT RRs > in the zone, so it's all good, right? > > > Thus, I maintain that we take our licks on this one and just take steps > to ensure that nobody follows this path again. > > And how do you propose that exactly, particularly given the precedent set > by SPFBIS? > Someone else (Joe, I think) has already referred to other RFCs that talk about things like IAB advice about how [not] to put application data into the DNS. Seems to me this is a perfectly good subject for another such project. One may counter that by saying nobody will pay attention to such a document, but I submit that it's our primary mechanism for making sure mistakes aren't re-made, so that's the tool we have to use or not use. If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT, then I still think we'll be shouting that to an audience that will think we're nuts and simply go about their business. -MSK --e89a8f646ff3e4184a04db3daa27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <drc@v= irtualized.org> wrote:
> So how much energy are the DNS experts = going to put into cleaning up their house while demanding the mail people c= lean up theirs?

So, this is about revenge because it used to be hard to get RRtypes?<= br>

Did I really come across as that petty?=

No, what I'm saying is that the way things were ten = years ago pushed the SPF community to the place it's in now, ugly as it= is.=A0 SPF, in the interim, has become very widely deployed.=A0 Suddenly n= ow we have a few voices from the ivory tower asserting that the same commun= ity needs to go out and re-do things the way they should have been done in = the first place, now that we finally have a somewhat more reasonable perspe= ctive, even though some of the vestiges of ten years ago are in fact still = around.=A0 My reaction to that is "You can't be serious."=A0 = That doesn't sound like revenge at all to me, just pragmatism.


> The deployed SPF base probably won't give a damn if the IETF sudde= nly releases an RFC that exclaims "Everybody migrate to type 99!"=

Yep. =A0This gets into projections about the future. =A0If SPF has to= pped out, it simply doesn't matter. =A0If SPF is going to continue to g= row, then it probably does matter.

I th= ink it's much closer to the former.
=A0
The point is that it isn't just fine. =A0It does have= operational impacts, from potentially increased fragmentation/fallback to = TCP to increased complexity in TXT RR parsers that have to distinguish betw= een the myriad of crap that's residing at the zone apex TXT RR, etc. = =A0Of course, most of these negative impacts are hidden to the folks who ar= e putting the TXT RRs in the zone, so it's all good, right?

> Thus, I maintain that we take our licks on this one and just take step= s to ensure that nobody follows this path again.

And how do you propose that exactly, particularly given the precedent= set by SPFBIS?

Someon= e else (Joe, I think) has already referred to other RFCs that talk about th= ings like IAB advice about how [not] to put application data into the DNS.= =A0 Seems to me this is a perfectly good subject for another such project.= =A0 One may counter that by saying nobody will pay attention to such a docu= ment, but I submit that it's our primary mechanism for making sure mist= akes aren't re-made, so that's the tool we have to use or not use.<= br>

If we do the opposite and someho= w compel SPFBIS to favour type 99 over TXT, then I still think we'll be= shouting that to an audience that will think we're nuts and simply go = about their business.

-MSK
--e89a8f646ff3e4184a04db3daa27-- From joelja@bogus.com Thu Apr 25 23:47:37 2013 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 BD97A21F97DF for ; Thu, 25 Apr 2013 23:47:37 -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 xnaJ6-qKOP2b for ; Thu, 25 Apr 2013 23:47:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8648D21F97D9 for ; Thu, 25 Apr 2013 23:47:33 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3Q6lW1E012537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 06:47:33 GMT (envelope-from joelja@bogus.com) Message-ID: <517A22FF.2090309@bogus.com> Date: Thu, 25 Apr 2013 23:47:27 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Jim Reid , Mark Andrews References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> In-Reply-To: <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 26 Apr 2013 06:47:33 +0000 (UTC) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 06:47:37 -0000 On 4/25/13 11:22 PM, Jim Reid wrote: > On 26 Apr 2013, at 01:46, Mark Andrews wrote: > >> The hardest thing is dealing with the naysayers. The entire BS >> that keeps getting repeated that getting a RR type is hard. > It's not BS. Getting new RRtypes is easier than it used to be (in principle) but it is not easy. Or at least, this WG creates the perception that it is not easy. Witness the recent pushback and BS around Joe's EUI{48,64} RRtypes. BWT, this was AFTER the RRtype Allocation Policy of RFC6895 had been followed and IANA had issued the type codes. That resistance from this WG -- "I'm in favour of liberalising type code assignments, but..." -- was not an isolated event. Well realistically, the WG is closing down so work that would involve draft(s) being accepted and processed would occur elsewhere. I brought the discussion here, when considering whether to AD sponsor the draft because there is a critical mass of knowledge here that is useful for providing feedback. There was useful criticism that lead to the draft being revised... There was also criticism of the codepoint assignment that's all well and good. but this wg isn't in the code point assignment path so that's not germain. There is criticism that there are better ways to do this. (I'm sure there are) that's fine, good enough should not be our enemy. were this not to achieve the required consensus I see not reason why the IESG would prevent and indepedent stream documentation of the codepoint assignment. It's disappointing but not surprising if others take the path of least resistance and go with a TXT record and avoid the hassle of the RFC6895 template and expert review. Not because that process is defective, but because the BS that tends to surface on this list. Having been on the receiving end of that treatment, I would think long and hard about coming to the IETF with a request for a new RRtype code instead of doing the "wrong" thing by following the herd and overloading the TXT record. Or just plucking a number from the reserved for private use range and hoping nobody else picks the same one. I think we can demonstrate that RFC6895 assignment process is less onerous than the mailing list discussion. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Thu Apr 25 23:52:45 2013 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 68C6B21F97D1; Thu, 25 Apr 2013 23:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 K9aaE7ipexBL; Thu, 25 Apr 2013 23:52: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 6F05121F97BF; Thu, 25 Apr 2013 23:52:41 -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 395FA5F98E9; Fri, 26 Apr 2013 06:52:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366959158; bh=7tJjS48HL6RtN7auaCrBHrzhQ3/OaPOuqXLKM23DvaY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=OelgbkhzB2FvIc9gpyVXS0g+mZW37M8wohD8b8z//jXHYr7qarKZTP4vGn/cgLk4w SckoHq6yGE/EGZ+XVB2lv0QWs4ZCsdggQIZuZB/nUnYn53WLOe39v3yrdNzqpA/GWX Qj3CTXVEOqoFiUzMg9uxrhkFSizKX4l72U0hpmf0= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (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 BC395216C40; Fri, 26 Apr 2013 06:52:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D8E8133032DC; Fri, 26 Apr 2013 16:52:21 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> In-reply-to: Your message of "Thu, 25 Apr 2013 20:29:14 -0700." Date: Fri, 26 Apr 2013 16:52:21 +1000 Message-Id: <20130426065221.D8E8133032DC@drugs.dv.isc.org> Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:52:45 -0000 In message , "Murray S. Kucherawy" writes: > > On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > > > Yep, been there, done that. It was a bad decision then, and it's still a > > bad decision now. I realize that it's incredibly unpopular to bluntly call > > bad decisions "bad decisions," but not doing so doesn't make them any less > > bad. And, to make matters worse, not doing so has led to a non-trivial > > number of those bad decisions becoming de facto standards. This has at > > least 2 very bad side effects ... first, we have to live with the bad de > > facto standards; but more importantly we are providing encouragement to > > people who wish to make similar bad decisions down the road. > > > > The argument in 6686 boils down to, "We made a series of bad decisions, > > which have led to a bad result. We now want to codify that bad result > > instead of cleaning up our mess." I don't agree with that in principle, and > > I don't agree with that in regards to this particular case. > > > > Further, while cleaning up the SPF mess would require nothing more than a > > marginal amount of extra work now, plus the passage of time, there is no > > reason not to actually clean up the mess. > > > I think this continues to trivialize exactly what it means to migrate the > enormous deployed base of SPF in the manner you're pushing. I fully agree > with your premise that it should've been "done right" in the beginning and > I lament that it was not, but I don't agree that fixing this now is worth > moving a mountain, especially when I don't believe the people saying that > here will be among the people doing even a fraction of the moving. The installed base of SPF is miniscule. As for moving it, you really only need to update a couple MTA's to use the SPF libraries that look for SPF first and let time pass. If you want a hurry on one could add code to nameservers and zone signers to detected TXT style spf records and add SPF records if they are missing. > At least half of the reason we landed here is because of an environment > that was basically hostile to doing it right in the first place. The rules > for getting new RRtypes have been improved -- The rules were dead simple at the time, just nobody in the SPF camp was willing to try to go down that route. I know they were simple because I used them at the time for another type. > I think we all agree on that > -- but, as you already conceded, there's still a large deployed base of > faulty firewalls and DNS tools out there that don't exactly make use of > uncommon RRtypes easy. So how much energy are the DNS experts going to put > into cleaning up their house while demanding the mail people clean up > theirs? I would even go so far as to say that the DNS part has to happen > first, before any cleanup on the email side is practical to consider. The DNS had deployed support for UNKNOWN RR types at the time. Most resolvers have been able to lookup unknown types since RFC 1034 was published. For most resolvers it was simply a matter of using 99 rather than a symbolic name. > The deployed SPF base probably won't give a damn if the IETF suddenly > releases an RFC that exclaims "Everybody migrate to type 99!" From the > perspective of large and small operators around the world, what's out there > is working now, and messing with it is asking for pain; engineers' time to > switch and debug costs a lot of money, so they have no incentive whatsoever > to comply with a proposed change to "fix" a service that is philosophically > broken but operationally just fine. > > Thus, I maintain that we take our licks on this one and just take steps to > ensure that nobody follows this path again. > > -MSK -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jim@rfc1035.com Fri Apr 26 00:14:05 2013 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 CD0E621F97A6 for ; Fri, 26 Apr 2013 00:14:05 -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 GzX+hZCVeNu1 for ; Fri, 26 Apr 2013 00:14:05 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 5439721F979F for ; Fri, 26 Apr 2013 00:14:05 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [IPv6:2001:4b10:100:7::42]) by shaun.rfc1035.com (Postfix) with ESMTP id 70CEBCBC41F; Fri, 26 Apr 2013 08:14:04 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <20130426063000.0A9A13303183@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 08:14:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68361517-94CF-4A91-9251-573167CA6C58@rfc1035.com> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> <20130426063000.0A9A13303183@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 07:14:05 -0000 On 26 Apr 2013, at 07:29, Mark Andrews wrote: > The type code is allocated. Code supporting EUI48 and EUI64 has > shipped. BIND 9.6, 9.8 and 9.9 all support EUI48 and EUI64. The > rest is bikeshedding. Indeed. My point is/was that the bikeshedding and other showboating in = this WG create the perception that getting type codes is hard. From jim@rfc1035.com Fri Apr 26 00:27:56 2013 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 5986C21F97EF for ; Fri, 26 Apr 2013 00:27:56 -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 gttZZu9Iu+Kh for ; Fri, 26 Apr 2013 00:27:56 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6221F8900 for ; Fri, 26 Apr 2013 00:27:55 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [IPv6:2001:4b10:100:7::42]) by shaun.rfc1035.com (Postfix) with ESMTP id DA9A2CBC41F; Fri, 26 Apr 2013 08:27:49 +0100 (BST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <517A22FF.2090309@bogus.com> Date: Fri, 26 Apr 2013 08:27:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <077D73D9-1E5F-431C-95D4-1D01D49853DC@rfc1035.com> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> <517A22FF.2090309@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 07:27:56 -0000 On 26 Apr 2013, at 07:47, joel jaeggli wrote: > I think we can demonstrate that RFC6895 assignment process is less = onerous than the mailing list discussion. Fine. However the latter is more visible =3D> creating the perception = that getting type codes is "hard". From sm@elandsys.com Fri Apr 26 02:03:03 2013 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 E10EF21F97D3; Fri, 26 Apr 2013 02:03:03 -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 p3owoQrR41GG; Fri, 26 Apr 2013 02:03:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B621F97C9; Fri, 26 Apr 2013 02:03:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3Q92i2G007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 02:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366966977; bh=gW+kdAjlRGcjp+2QjQjCLOnZbi3VKvHBRy5DmVRzSmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W5mD3dD0DnhVS7iZs+q66/1c87YvnbiFLPpnf01y821QDTiBnxa55SuKP4R/QsJlH MHm9E0uo/2KYy04i1K5OwZj68xatXS1RNiTR6fdch5QKKgg872FUlLbTwFNOMCtrr6 MY7U/lLPS9oab0W3tu+bMorzcAcYF2GWTzO+yd2I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366966977; i=@elandsys.com; bh=gW+kdAjlRGcjp+2QjQjCLOnZbi3VKvHBRy5DmVRzSmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3n5mf3CJbdJ963XByMCKp4qzK/13cKSjqWYzJ3fwx+BaX9f5ynhjaGsY4ss/TDJA7 5S4JEgrBjXoKcOtwqpkqEtFrACb+CIleeat2ldPfrkB22OEtey92otkYlzZpZlK9Mu SDeRZkSARwDOegCKJr3/5WCiPAQ4XGiz9V2w3RLM= Message-Id: <6.2.5.6.2.20130425230637.0d0010e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 01:28:14 -0700 To: Doug Barton From: S Moonesamy In-Reply-To: <5179D8C3.8090207@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <5179D8C3.8090207@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 09:03:04 -0000 Hi Doug, At 18:30 25-04-2013, Doug Barton wrote: >Note, I'm going to push back on some of the things you say below, >but I don't want the main point I'm trying to make to get lost: > >1. It's not too late to do the right thing, >2. So we should do that. I'll comment below. >There are only so many times that people can say "this is a bad >idea," then get ignored, and then have enthusiasm to come back and >say the same thing again. I didn't follow the Ok. > pre-publication of 6686, as I had other things to do at the time. > However the volume of previous discussion over the last 8+ years > should have been sufficient to render the idea of deprecating the > SPF RRtype a non-starter. The fact that the draft got written in > the first place said a lot about the chances of any objections > being considered. When the work started nobody knew what to do. The following comment was made around a year ago: "the IESG would simply like to see the SPF *and* Sender-ID experiments wrapped up, and presumes that the charter is correct and the outcome of the experiment leads one to conclude that SPF should get advanced to Proposed Standard and Sender-ID should not". In easy terms, it would be good to have a conclusion to those experiments. There was an assumption, i.e. SPF would get advanced. My guess (not technically sound) was that there was a higher chance of that happening (e.g. see http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html ). There is a short discussion predating Issue #9 (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html ). Philip Gladstone provided some data (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html ). Issue #9 was opened based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html draft-kucherawy-spfbis-experiment was posted after that (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00405.html ). There were comments mentioning the ietf@ discussion ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00789.html ). Anyway, the working group decision about the protocol aspect was made based on the analysis. The question of whether to obsolete the SPF RRTYPE or not is an administrative issue. That is why it is in the IANA Considerations Section of draft-ietf-spfbis-4408bis-14. I am ok with whatever the IETF decides about that. There are several intermingled issues. If I understood correctly the main issue is which DNS RR to use to publish SPF information in the DNS. I suggest discussing about that during the Last Call for draft-ietf-spfbis-4408bis. >I have to respectfully point out that a) there is a wider world >beyond spfbis, and b) the reasoned technical arguments that were >presented on the list (not to mention the running code) should have >been sufficient to push the group in the direction of preferring the >SPF RRtype with an eye toward deprecating TXT in the future. I am aware of that. :-) There isn't much I can do about it. My task was to give due consideration to all the arguments that were presented on this mailing list. Technical arguments are obviously more compelling. If there are any new arguments which have been missed please let me know as I can include them in my write-up. If the argument is solely "do the right thing" I will decline including it in the write-up as it is, in my individual opinion, non-technical. I cannot comment on what arguments should be provided as I will then be biasing the outcome. Regards, S. Moonesamy From Ted.Lemon@nominum.com Fri Apr 26 04:12:00 2013 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 B03D521F9876 for ; Fri, 26 Apr 2013 04:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.733 X-Spam-Level: X-Spam-Status: No, score=-105.733 tagged_above=-999 required=5 tests=[AWL=0.866, 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 dwoocZdPa92q for ; Fri, 26 Apr 2013 04:11:59 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id AE85921F9822 for ; Fri, 26 Apr 2013 04:11:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUXpg/jUyKp3MLTIy7gMGvzDDMhFepr9B@postini.com; Fri, 26 Apr 2013 04:11:58 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D49AE1B80DF for ; Fri, 26 Apr 2013 04:11:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CC44E190061; Fri, 26 Apr 2013 04:11:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 04:11:57 -0700 From: Ted Lemon To: Jim Reid Thread-Topic: [dnsext] getting people to use new RRTYPEs Thread-Index: AQHOQgAKmbqqIBDfGUqSx8JOnKnZJZjnqx42gADTHICAAAbzgIAAC0YAgAA+nwA= Date: Fri, 26 Apr 2013 11:11:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515F6C4@mbx-01.win.nominum.com> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <9A4E511F-92E1-4286-AD91-4E438C821774@rfc1035.com> <517A22FF.2090309@bogus.com> <077D73D9-1E5F-431C-95D4-1D01D49853DC@rfc1035.com> In-Reply-To: <077D73D9-1E5F-431C-95D4-1D01D49853DC@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 11:12:00 -0000 On Apr 26, 2013, at 3:27 AM, Jim Reid wrote: > Fine. However the latter is more visible =3D> creating the perception tha= t getting type codes is "hard". I think that if you want to get a document through the IETF, and you say "o= h, but I don't want to do that bit, because it's too hard," then you are re= ally being unreasonable. During the worst period of "new RRtype resistanc= e" about a decade ago, I and several others managed to get a new RRtype thr= ough the intarea DNS working group. We did get yelled at, but we persiste= d, and we got the result we wanted. This is how the IETF works. You are watching sausage being made: it isn't= pretty. No amount of public shaming is going to change this: the current= conversation is an existence proof, since this sort of shaming has been go= ing on as long as I've been participating, and the mailing list still has t= hreads like the EUI64 thread. This is what it means to say anyone can par= ticipate. If you want to get work through the IETF, you have to be brave, because you= will=97you must=97draw criticism. And you don't get to say "I want to ge= t my work through the IETF, but I'd like to skip that bit of the process be= cause those guys are hard to deal with, please." All of this is completely independent of the debate that's going on here ab= out SPF; my point is simply that if you aren't willing to engage in debate = in the IETF, you are probably in the wrong IETF.= From ajs@anvilwalrusden.com Fri Apr 26 05:14:30 2013 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 F06D621F988B for ; Fri, 26 Apr 2013 05:14:29 -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 fhXRuj9PsxNG for ; Fri, 26 Apr 2013 05:14:29 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46521F988A for ; Fri, 26 Apr 2013 05:14:29 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8999E8A031 for ; Fri, 26 Apr 2013 12:14:27 +0000 (UTC) Date: Fri, 26 Apr 2013 08:14:24 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130426121424.GA349@mx1.yitter.info> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <5179DB4B.2040403@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5179DB4B.2040403@dougbarton.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 12:14:30 -0000 I am speaking here as an individual and as an operator. On Thu, Apr 25, 2013 at 06:41:31PM -0700, Doug Barton wrote: > 1. Insert the ability into the interface to add freeform stuff > 2. Run the equivalent of named-checkzone prior to committing the change > 3. Profit! That's preposterously naive. Step 2.1 is "Find that customer who has no theory of the mystifying DNS arcana screwed it up, so you can't publish, and now you have to contact a human. Stop. Invoke expensive off-page customer service process." In some significant number of cases, we never get to step 3. In the DNS business, the margins are small. This list -- and indeed, much of the IETF, as is often lamented -- is heavily populated by people who either are not operators or else are not consumer-facing operators, though there are notable exceptions. It sseems at least possible that this introduces a bias of ignoring problems that others report (or that are observable in deployment) because they're not the problems of the people who happen to be here. I have to agree with John Levine that the usual answer of the DNS community to provisioning problems -- in caricature, "This is easy, you must be morons." -- is not helpful, and is indicative of a closed mindedness that is unbecoming. Maybe, just maybe, the people out there who are successfully operating systems at some scale have something to teach us about the real barriers to the things we think would be ideal. We dismiss those observations not at our peril, but at the peril of the DNS (and Internet). A -- Andrew Sullivan ajs@anvilwalrusden.com From mansaxel@besserwisser.org Fri Apr 26 05:40:35 2013 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 27EA621F9831 for ; Fri, 26 Apr 2013 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4jZUm8cG6lf for ; Fri, 26 Apr 2013 05:40:34 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 853AD21F97E3 for ; Fri, 26 Apr 2013 05:40:33 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id AF1AD9EF0; Fri, 26 Apr 2013 14:40:32 +0200 (CEST) Date: Fri, 26 Apr 2013 14:40:32 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Andrew Sullivan Message-ID: <20130426124032.GT23770@besserwisser.org> References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <5179DB4B.2040403@dougbarton.us> <20130426121424.GA349@mx1.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZXzThk3vFZecBD04" Content-Disposition: inline In-Reply-To: <20130426121424.GA349@mx1.yitter.info> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 12:40:35 -0000 --ZXzThk3vFZecBD04 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] getting people to use new RRTYPEs Date: Fri, Apr 26, = 2013 at 08:14:24AM -0400 Quoting Andrew Sullivan (ajs@anvilwalrusden.com): > I have to agree with John Levine that the usual answer of the DNS > community to provisioning problems -- in caricature, "This is easy, > you must be morons." -- is not helpful, and is indicative of a closed > mindedness that is unbecoming. =20 The proper answer is "This ought to be easy, and usually is, but half-assed implementations that are in conflict with both letter and intent of the DNS standards and culture make it unnecessarily hard, for some people. Vendors most of the time act against better knowledge because of reasons. This is moronic." /M=C3=A5ns, ivory-tower-sited operator of DNS zones and email servers.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 My haircut is totally traditional! --ZXzThk3vFZecBD04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF6dcAACgkQ02/pMZDM1cWbDQCfQiA4YalulS3HrGfCv/1E9mNw Z+IAoI02CS3Uvseg/NsQyqr/LHqSuYcF =2awH -----END PGP SIGNATURE----- --ZXzThk3vFZecBD04-- From Ted.Lemon@nominum.com Fri Apr 26 06:41:48 2013 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 D894521F9981; Fri, 26 Apr 2013 06:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.179 X-Spam-Level: X-Spam-Status: No, score=-105.179 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb68rLZ4VbmT; Fri, 26 Apr 2013 06:41:46 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F921F98C9; Fri, 26 Apr 2013 06:41:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqEGW8bjYsGk1wCZNNVp2M6r3tMOj4T@postini.com; Fri, 26 Apr 2013 06:41:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 934B41B80C4; Fri, 26 Apr 2013 06:41:45 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 619A9190061; Fri, 26 Apr 2013 06:41:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 06:41:33 -0700 From: Ted Lemon To: S Moonesamy Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQhiJDTN43HbFiUKXXg4sKsK6S5jo+K0A Date: Fri, 26 Apr 2013 13:41:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> In-Reply-To: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19FD30E1F7D6AD4284DBC4023708C9F0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 13:41:49 -0000 [This is really long, because I've spent a lot of time thinking about this = and reading the discussion; the tl;dr is that I don't intend to contest the= obsoleting of the SPF RRtype any further, but would not fault = others for doing so, and I think there are lessons to be lear= ned about how the process went this time, which, if you are interested i= n that, might be a good reason to continue reading.] On Apr 25, 2013, at 8:22 PM, S Moonesamy wrote: > I am ok if anyone says that it a bad decision. The thread for the discus= sion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg0042= 6.html I undertook the exercise of reading this thread, and it looks like there wa= s some very interesting data collection work done. I didn't find a point = at which a consensus was determined; I presume that happened later, on some= other thread. > I was the document shepherd for RFC 6686. There wasn't any comments duri= ng the Last Call. FWIW, and I do not intend this as a criticism of what you did, I just went = back to the datatracker and looked at the text of the IETF last call. The= re is nothing at all in this text that would indicate that the document sai= d anything at all about the continued use of the SPF DNS RRtype. I've als= o read the document, and even reading the conclusion of the document, there= 's very little there that would suggest to me that the spfbis working group= was about to deprecate the use of the SPF DNS RRtype. Of course someone who was already involved in the discussion on the mailing= list would know this, but there's no reason to think that anyone reading t= he dnsext mailing list would have felt it was their duty to review this par= ticular document during the IETF last call, and if they had reviewed it, th= ey might still have remained innocent of any understanding that spfbis inte= nded to deprecate the SPF RRtype in favor of the TXT record. > If there are any new arguments which have been missed please let me know = as I can include them in my write-up. If the argument is solely "do the ri= ght thing" I will decline including it in the write-up as it is, in my indi= vidual opinion, non-technical. I cannot comment on what arguments should b= e provided as I will then be biasing the outcome. It seems to me that the argument in favor of deprecating SPF is that nobody= is publishing SPF records, despite widespread support in software. This = results in unnecessary traffic, the elimination of which would have minimal= impact. On the other side, here are the arguments that I understand to have been ma= de: 1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record. Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached. 2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP. Rejoinder: doesn't seem to be an issue in practice. 3. Using TXT records is a bad idea. Rejoinder: this isn't really a technical argument; if there is a technical = argument in here, it should be stated explicitly, but this argument per se = will be ignored. 4. Using TXT records sets a bad precedent. Rejoinder: the horse is already out of the barn. I think there's one possible benefit to be considered for using TXT records= for SPF: it gets in the way of other uses of TXT records, and acts as a so= und technical argument against adoption of TXT records on bare names in fut= ure protocols. Speaking entirely with my AD hat off, and merely as an armchair quarterback= , I don't think it's fair to say that the consensus call in spfbis on what = was to become RFC6686 and the IETF consensus call on that document, taken t= ogether, represent IETF consensus. I don't think the rejoinders to argume= nts 1 and 2 are very convincing, although they seem to have carried the day= in the spfbis working group, and I understand why. The reason I reacted the way I did when drc brought this up is that it was = a surprise to me that spfbis was eliminating the SPF record from the specif= ication. It is not surprising that it was a surprise=97the process that w= as followed, which I think was followed correctly and with the best intenti= ons, did not really have much chance of bringing this decision to my attent= ion while it was being discussed in spfbis. Having reviewed the discussion in spfbis, and argued with this at length wi= th Pete, I am remarkably ambivalent about it. I don't like the decision t= he spfbis working group has made. I don't agree with the decision. I unde= rstand why you made it, and don't fault you for having made it. It's prob= ably not worth my personal time to dispute it. I would rather work to hasten the demise of SMTP and all the anti-spam klud= ges that rode in on it. So, what do I think could have gone better here? First, it would have bee= n very helpful if the abstract for RFC 6686 had said that the reason the re= search was being done was to answer the question "should we continue suppor= ting the SPF RRtype, or drop it?" Authors of drafts that are trying to ad= dress issues like this might want to think carefully about how they write a= bstracts, since it's only the abstract that gets shown in the IETF last cal= l message. If your abstract doesn't attract the people who ought to be re= ading the document, it's going to be hard later to argue that the document = had a clear IETF consensus, even though it nominally has consensus. It may be that using the document abstract in the last call announcement is= not sufficient=97if authors phrased the abstract the way I've suggested, i= t might be the wrong thing for the document once it's published. I don't = know the answer to this=97it might also be the right thing. I think it's clear that early in this discussion, all present, including th= e responsible AD, were aware that it was going to be contentious. I think= if a message like the one drc sent to the mailing list yesterday had gone = out in February of 2012, you would have gotten the exact same response. T= his probably would have created additional hassle on the spfbis mailing lis= t as a bunch of dnsext people dogpiled there, but we wouldn't be having _th= is_ conversation _now_, so it actually would have been better, despite the = short-term hassle. Andrew did raise this issue to the dnsop working group; he didn't mention r= aising it on dnsext. I don't remember seeing it on the dnsop mailing list= , and I'm not finding it in the archive; I don't see it in the minutes eith= er. This doesn't mean it isn't there; it just means that it didn't stand = out the way drc's message did. This ought to be a valuable lesson for wor= king group chairs; if you know something is going to be contentious, rip th= e bandaid off=97don't be quiet about it. Make sure the people who you kno= w are going to kick up a fuss do it at the right time. I know Andrew didn= 't intend to not rip off this bandaid, so I'm not sure how this failed to h= appen, but it's something to think about. The responsible AD also knew this was going to be contentious (I think!). = I don't know if he talked this over with Ralph (who was then the responsib= le AD for dnsext) or not. If he did, that was the right thing to do, and = it's worth considering why it didn't work. If he didn't, this might be a = lesson to remember for the future. Same thing should have happened with t= he responsible AD for dnsop; I don't know who that was. Of course, ADs don't always know that what's being raised in the working gr= oup is going to be contentious in other areas. Working group chairs need = to be proactive about this. ADs can definitely be a resource in spreading= the word, though, whether they do it on their own or at the request of wor= king group chairs. And of course working group chairs may not always know= that something will be contentious, but there's nothing we can do about th= at case other than live with the late surprise. I hasten to emphasize that I don't really know what went wrong here. It m= ay be that even if all the remedies I've discussed above had happened, we'd= still be having a big kerfuffle about this on the dnsext mailing list. M= y motivation for suggesting that more could have been done is simply my exp= erience as a participant: I really think I would have participated in the d= iscussion about this if I'd realized it was happening last February. I get= the impression from several other participants in the discussion now that = they weren't aware of it either. I don't have a sense of whether the disc= ussion would have come out differently if we'd participated. As for how to participate now, the right thing to do for people who feel th= ey were left out of the discussion before is to read the draft, read the hi= storical discussion (to which pointers have already been given) and then pa= rticipate constructively on the spfbis working group mailing list. "Tromping" on this in IETF last call would not be constructive given that i= t has not passed a working group last call. I'm sorry for having suggested= that=97I understood the document to have already passed WGLC, and stupidly= didn't go check to see if my impression was correct. And, by the way, internet dating is quite a lucrative industry, so it's pro= bably a bad example of a hopeless task. :) From Ted.Lemon@nominum.com Fri Apr 26 07:00:59 2013 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 AC8C321F9955; Fri, 26 Apr 2013 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.016 X-Spam-Level: X-Spam-Status: No, score=-106.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 URTHp-rGY6Du; Fri, 26 Apr 2013 07:00:59 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8E21F994E; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqImjAQxeTP21ZZVCfUgyEIFpPfYsm1@postini.com; Fri, 26 Apr 2013 07:00:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC1221B80CF; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A59FF190061; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 07:00:58 -0700 From: Ted Lemon To: S Moonesamy Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQhiJDTN43HbFiUKXXg4sKsK6S5jo+K0AgAAFbYA= Date: Fri, 26 Apr 2013 14:00:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515FF39@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <053DFE13F90022448D6BBD3757DD2243@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 14:00:59 -0000 On Apr 26, 2013, at 9:41 AM, Ted Lemon wrote: > Speaking entirely with my AD hat off, and merely as an armchair quarterba= ck, I don't think it's fair to say that the consensus call in spfbis on wha= t was to become RFC6686 and the IETF consensus call on that document, taken= together, represent IETF consensus. I don't think the rejoinders to argu= ments 1 and 2 are very convincing, although they seem to have carried the d= ay in the spfbis working group, and I understand why. Argh. I can't say anything right, apparently. What I mean here is that = the consensus call in the working group and the subsequent consensus call o= n the IETF mailing list do not mean that the IETF definitely has consensus = to deprecate the SPF RRtype. They do mean that the IETF had consensus to = publish the document. Sorry for putting that so badly. From superuser@gmail.com Fri Apr 26 07:52:33 2013 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 ED50B21F9A3C; Fri, 26 Apr 2013 07:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PfJoYPJvOC-d; Fri, 26 Apr 2013 07:52:32 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9002F21F9A2B; Fri, 26 Apr 2013 07:52:31 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id m1so3627768wea.40 for ; Fri, 26 Apr 2013 07:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GZW0tvEsKM9+oW8N9592+eGj2eQxxaULB5tSdDWJ9bE=; b=kp4+f/etl6gT3lTOYIgjXY4uUuHT+oNVvnHtPBUvlDv4mJpdbLoWJdO2MyyB93hedj CkXuApxVtxjCMQbodo3zZn+Cwx/yY7oWwavOL7xLL+bzDw90vzYEyQQk86nuY6sF7bv3 HbF7Z+cyLuXOL80st+/EwX0nEhD7GjfSZ1AeOE+2/iexsLJDXEt84BRMerw36DDqgXTL jECJKyeThkl33HVbt2Bh8eDacH/fo8AxCSvjzfhuMhfjVbiDIByH0I+mWCFlxpwdCreA idDdVvXbWExqu2Iii8gzSm9AOhNEqQtmnZOQI7mQIw0ifxkwfG8ySOcRvD0fvs5x+tjC 8lgw== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr4498560wix.20.1366987949493; Fri, 26 Apr 2013 07:52:29 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 07:52:29 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 07:52:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ted Lemon Content-Type: multipart/alternative; boundary=f46d041825382454fb04db44af4d Cc: "spfbis@ietf.org" , Pete Resnick , S Moonesamy , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 14:52:33 -0000 --f46d041825382454fb04db44af4d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon wrote: > FWIW, and I do not intend this as a criticism of what you did, I just wen= t > back to the datatracker and looked at the text of the IETF last call. > There is nothing at all in this text that would indicate that the documen= t > said anything at all about the continued use of the SPF DNS RRtype. I'v= e > also read the document, and even reading the conclusion of the document, > there's very little there that would suggest to me that the spfbis workin= g > group was about to deprecate the use of the SPF DNS RRtype. > RFC6686 never set out to make a conclusion about the RRtype question, but rather to determine which of the four protocols MARID discussed appear to have enough traction to warrant advancement along the standards track, thus concluding "the experiment". Accordingly, the abstract for that document doesn't say anything about this matter. In the process of collecting data to answer that question, we realized that the numbers also highlight the non-use of type 99 by both senders and receivers. We were very careful in our wording of RFC6686 to point out that type 99, though supported both in protocol and software, is actually not very useful, and said nothing at all about what we planned to do with it. RFC6686 provides supporting evidence for what the main spfbis draft is doing, but does not itself introduce those actions. I don't think there was process breakage here. > > It seems to me that the argument in favor of deprecating SPF is that > nobody is publishing SPF records, despite widespread support in software. > This results in unnecessary traffic, the elimination of which would have > minimal impact. > That's not the complete argument I and others have been making. Widespread support in DNS software and SPF libraries exists, but there are also existing components of the infrastructure that interfere with either publication or handling of type 99 queries and replies, long after the type was assigned. RFC6686 calls this out. The rejoinder we're hearing to this is merely the gainsay of that position despite both anecdotal and empirical evidence to the contrary. On the other side, here are the arguments that I understand to have been > made: > > 1. TXT records are not specific to SPF, thus we can't assume that any > given TXT record is an SPF record. > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records > are needed on the names to which SPF TXT records are typically attached. > Moreover, parsing TXT records is not hard, nor is answering the question "Does this one start with the string 'v=3Dspf1'?". We saw one case in our survey of a zone that had 37 TXT records at the same query point; SPF code is able to pull out the applicable one just fine. > > 2. Because TXT records aren't specific to SPF, a query for TXT records ma= y > return an unexpectedly large result set, requiring fallback to TCP. > Rejoinder: doesn't seem to be an issue in practice. > That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53. We discovered this during the RFC6686 surveys. -MSK --f46d041825382454fb04db44af4d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
FWIW, and I do not intend= this as a criticism of what you did, I just went back to the datatracker a= nd looked at the text of the IETF last call. =A0 There is nothing at all in= this text that would indicate that the document said anything at all about= the continued use of the SPF DNS RRtype. =A0 I've also read the docume= nt, and even reading the conclusion of the document, there's very littl= e there that would suggest to me that the spfbis working group was about to= deprecate the use of the SPF DNS RRtype.

RFC6686 never set out to make a conclusion= about the RRtype question, but rather to determine which of the four proto= cols MARID discussed appear to have enough traction to warrant advancement = along the standards track, thus concluding "the experiment".=A0 A= ccordingly, the abstract for that document doesn't say anything about t= his matter.

In the process of collecting data to answer that question, we realized = that the numbers also highlight the non-use of type 99 by both senders and = receivers.=A0 We were very careful in our wording of RFC6686 to point out t= hat type 99, though supported both in protocol and software, is actually no= t very useful, and said nothing at all about what we planned to do with it.= =A0 RFC6686 provides supporting evidence for what the main spfbis draft is = doing, but does not itself introduce those actions.

I don't think there was process breakage here.=A0
=A0

It seems to me that the argument in favor of deprecating SPF is that nobody= is publishing SPF records, despite widespread support in software. =A0 Thi= s results in unnecessary traffic, the elimination of which would have minim= al impact.

That's not the complete argument I and othe= rs have been making.=A0 Widespread support in DNS software and SPF librarie= s exists, but there are also existing components of the infrastructure that= interfere with either publication or handling of type 99 queries and repli= es, long after the type was assigned.=A0 RFC6686 calls this out.=A0 The rej= oinder we're hearing to this is merely the gainsay of that position des= pite both anecdotal and empirical evidence to the contrary.

On the other side, here are the arguments that I understand to have been ma= de:

1. TXT records are not specific to SPF, thus we can't assume that any g= iven TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice=97no other TXT recor= ds are needed on the names to which SPF TXT records are typically attached.=

Moreover, parsing TXT records is not h= ard, nor is answering the question "Does this one start with the strin= g 'v=3Dspf1'?".=A0 We saw one case in our survey of a zone tha= t had 37 TXT records at the same query point; SPF code is able to pull out = the applicable one just fine.
=A0

2. Because TXT records aren't specific to SPF, a query for TXT records = may return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

That's not correct; there are still packet filters out= there configured by default to disallow TCP over port 53.=A0 We discovered= this during the RFC6686 surveys.
=A0
-MSK
--f46d041825382454fb04db44af4d-- From nweaver@icsi.berkeley.edu Fri Apr 26 08:02:59 2013 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 C1A6721F996E; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ7SpwfwcMPO; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 562E421F9955; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 308992C400B; Fri, 26 Apr 2013 08:02:59 -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 5z-VsHBJwKLy; Fri, 26 Apr 2013 08:02:58 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DFBA72C4007; Fri, 26 Apr 2013 08:02:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 26 Apr 2013 08:02:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <803526C6-6812-45CC-AEFF-2336B1247F93@icsi.berkeley.edu> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: Pete Resnick , "dnsext@ietf.org" , S Moonesamy , "spfbis@ietf.org" , Ted Lemon Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:02:59 -0000 On Apr 26, 2013, at 7:52 AM, Murray S. Kucherawy = wrote: > 2. Because TXT records aren't specific to SPF, a query for TXT records = may return an unexpectedly large result set, requiring fallback to TCP. > Rejoinder: doesn't seem to be an issue in practice. >=20 > That's not correct; there are still packet filters out there = configured by default to disallow TCP over port 53. We discovered this = during the RFC6686 surveys. This is pretty rare but not nonexistent. If anyone cares, we have some names that test resolver->authority path = for truncation, and client->resolver path for proper truncation support. From Ted.Lemon@nominum.com Fri Apr 26 08:13:19 2013 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 6C62B21F990F; Fri, 26 Apr 2013 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.474, 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 1brJvkezOkst; Fri, 26 Apr 2013 08:13:18 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 020B221F988B; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqZjfIHjWRvXKTyCgTsHo/nlR6x4HJm@postini.com; Fri, 26 Apr 2013 08:13:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 878901B80DF; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7AA1E190061; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 08:13:17 -0700 From: Ted Lemon To: "Murray S. Kucherawy" Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQo2uaOnySfcNYkaWBgVmragk3ZjpEWOA Date: Fri, 26 Apr 2013 15:13:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_" MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , S Moonesamy , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:13:19 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy > wrote: RFC6686 never set out to make a conclusion about the RRtype question, but r= ather to determine which of the four protocols MARID discussed appear to ha= ve enough traction to warrant advancement along the standards track, thus c= oncluding "the experiment". Accordingly, the abstract for that document do= esn't say anything about this matter. In the process of collecting data to answer that question, we realized that= the numbers also highlight the non-use of type 99 by both senders and rece= ivers. We were very careful in our wording of RFC6686 to point out that ty= pe 99, though supported both in protocol and software, is actually not very= useful, and said nothing at all about what we planned to do with it. RFC6= 686 provides supporting evidence for what the main spfbis draft is doing, b= ut does not itself introduce those actions. I don't think there was process breakage here. Okay, fair enough. Please do note that I didn't say that there was proces= s breakage=97I said the process seemed to have been followed correctly, but= produced a less than perfect outcome. The sense in which I mean that with respect to RFC 6686 is that several peo= ple have mentioned the IETF last call on RFC 6686 as if it means that the I= ETF now has an opinion on whether to deprecate SPF. It sounds like we bot= h agree that it does not, so this wouldn't be an example of process breakag= e. However, if people came to the conclusion that it did mean that, it's = worth talking about. That's not the complete argument I and others have been making. Widespread= support in DNS software and SPF libraries exists, but there are also exist= ing components of the infrastructure that interfere with either publication= or handling of type 99 queries and replies, long after the type was assign= ed. RFC6686 calls this out. The rejoinder we're hearing to this is merely= the gainsay of that position despite both anecdotal and empirical evidence= to the contrary. OK. But presumably these parts of the internet are going to start really = seriously breaking as IPv6 and DNSSEC deployment increase. So this doesn'= t _seem_ like a long-term concern. What am I missing? On the other side, here are the arguments that I understand to have been ma= de: 1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record. Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached. Moreover, parsing TXT records is not hard, nor is answering the question "D= oes this one start with the string 'v=3Dspf1'?". Sure, and a base-64 encoded string will never have an equals sign in that p= osition, so we don't have to worry too much about a random collision. We saw one case in our survey of a zone that had 37 TXT records at the sa= me query point; SPF code is able to pull out the applicable one just fine. 2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP. Rejoinder: doesn't seem to be an issue in practice. That's not correct; there are still packet filters out there configured by = default to disallow TCP over port 53. We discovered this during the RFC668= 6 surveys. These two points taken together seem like a pretty strong argument in favor= of _not_ deprecating the SPF record; in this case, only the SPF record wou= ld have made it back to the MTA. --_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <24FD6E35C2265D489ABE512883EFE458@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
RFC6686 never set out to make a conclusion about the RRtype question, = but rather to determine which of the four protocols MARID discussed appear = to have enough traction to warrant advancement along the standards track, t= hus concluding "the experiment".  Accordingly, the abstract for that document doesn't say anything about thi= s matter.

In the process of collecting data to answer that question, we realized that= the numbers also highlight the non-use of type 99 by both senders and rece= ivers.  We were very careful in our wording of RFC6686 to point out th= at type 99, though supported both in protocol and software, is actually not very useful, and said nothing at al= l about what we planned to do with it.  RFC6686 provides supporting ev= idence for what the main spfbis draft is doing, but does not itself introdu= ce those actions.

I don't think there was process breakage here. 

Okay, fair enough.   Please do note that I didn't say that there was p= rocess breakage=97I said the process seemed to have been followed correctly= , but produced a less than perfect outcome.

The sense in which I mean that with respect to RFC 6686 is that severa= l people have mentioned the IETF last call on RFC 6686 as if it means that = the IETF now has an opinion on whether to deprecate SPF.   It sounds l= ike we both agree that it does not, so this wouldn't be an example of process breakage.   However, if people= came to the conclusion that it did mean that, it's worth talking about.

That's not the complete argument I and others have been making.  = Widespread support in DNS software and SPF libraries exists, but there are = also existing components of the infrastructure that interfere with either p= ublication or handling of type 99 queries and replies, long after the type was assigned.  RFC6686 calls this ou= t.  The rejoinder we're hearing to this is merely the gainsay of that = position despite both anecdotal and empirical evidence to the contrary.

OK.   But presumably these parts of the internet are going to start re= ally seriously breaking as IPv6 and DNSSEC deployment increase.   So t= his doesn't _seem_ like a long-term concern.   What am I missing?

On the other side, here are the arguments that I understand to have been ma= de:

1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached.

Moreover, parsing TXT records is not hard, nor is answering the questi= on "Does this one start with the string 'v=3Dspf1'?".

Sure, and a base-64 encoded string will never have an equals sign in that p= osition, so we don't have to worry too much about a random collision.

  We saw one case in our survey of a zone that had 37 TXT records= at the same query point; SPF code is able to pull out the applicable one j= ust fine.


 

2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

That's not correct; there are still packet filters out there configure= d by default to disallow TCP over port 53.  We discovered this during = the RFC6686 surveys.

These two points taken together seem like a pretty strong argument in = favor of _not_ deprecating the SPF record; in this case, only the SPF recor= d would have made it back to the MTA.


--_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_-- From nweaver@icsi.berkeley.edu Fri Apr 26 08:16:56 2013 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 EA14F21F99A4; Fri, 26 Apr 2013 08:16:56 -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 KDXdZR0Wt-o8; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 214AF21F998C; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0B5F52C400C; Fri, 26 Apr 2013 08:16:56 -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 3HBYOt3KLgTP; Fri, 26 Apr 2013 08:16:55 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A38242C400B; Fri, 26 Apr 2013 08:16:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 08:16:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: Pete Resnick , S Moonesamy , "dnsext@ietf.org" , "spfbis@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:16:57 -0000 On Apr 26, 2013, at 8:13 AM, Ted Lemon wrote: >> On the other side, here are the arguments that I understand to have = been made: >>=20 >> 1. TXT records are not specific to SPF, thus we can't assume that any = given TXT record is an SPF record. >> Rejoinder: doesn't seem to be an issue in practice=97no other TXT = records are needed on the names to which SPF TXT records are typically = attached. >>=20 >> Moreover, parsing TXT records is not hard, nor is answering the = question "Does this one start with the string 'v=3Dspf1'?". >=20 > Sure, and a base-64 encoded string will never have an equals sign in = that position, so we don't have to worry too much about a random = collision. Yeah, we don't. =20 IF the string is random, thats a 1 in 2^36 chance. Yawn. And if the string is "malicious" and deliberately constructed to be a = bad record starting with v=3Dspf1, it only screws up the domain owner's = SPF record, so who gives a flying fig? The domain owner can correct it, = be done with it, and move on. >> 2. Because TXT records aren't specific to SPF, a query for TXT = records may return an unexpectedly large result set, requiring fallback = to TCP. >> Rejoinder: doesn't seem to be an issue in practice. >>=20 >> That's not correct; there are still packet filters out there = configured by default to disallow TCP over port 53. We discovered this = during the RFC6686 surveys. >=20 > These two points taken together seem like a pretty strong argument in = favor of _not_ deprecating the SPF record; in this case, only the SPF = record would have made it back to the MTA. If you want DNSSEC, you got to fix THAT problem anyway. From Ted.Lemon@nominum.com Fri Apr 26 08:32:02 2013 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 094EB21F99E4; Fri, 26 Apr 2013 08:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 O4-GXH2Zq4Uz; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6E04E21F99BB; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqd8XlTOTiex1mgGcShHgwTVs97z8IT@postini.com; Fri, 26 Apr 2013 08:32:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DF791B8152; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F1A5A190061; Fri, 26 Apr 2013 08:32:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 08:32:01 -0700 From: Ted Lemon To: Nicholas Weaver Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQpEXYsxqRLAjJkK9cjiqS/EnTJjpFpiA Date: Fri, 26 Apr 2013 15:32:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751603CA@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> In-Reply-To: <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <436DC312E1B0264E9F948509D099AA0B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , S Moonesamy , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:32:02 -0000 On Apr 26, 2013, at 11:16 AM, Nicholas Weaver w= rote: > IF the string is random, thats a 1 in 2^36 chance. Yawn. >=20 > And if the string is "malicious" and deliberately constructed to be a bad= record starting with v=3Dspf1, it only screws up the domain owner's SPF re= cord, so who gives a flying fig? The domain owner can correct it, be done = with it, and move on. Right. > If you want DNSSEC, you got to fix THAT problem anyway. This is a non-sequitur. From barryleiba.mailing.lists@gmail.com Fri Apr 26 09:53:37 2013 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 D5AC921F9653; Fri, 26 Apr 2013 09:53:31 -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 GmiH+GogDnxy; Fri, 26 Apr 2013 09:53:30 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 297DF21F992B; Fri, 26 Apr 2013 09:53:30 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ia10so2673739vcb.32 for ; Fri, 26 Apr 2013 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jS1z0glCyII8ThtjIaD8QyildjjHMKmnbrC4E2nCZjI=; b=GC6tQAOm+D14ukRsT6BWNRgG8Ge6ejs2VP+k/OIqbhOF06H/0HCVlEzhI7N/TawqoF W2TfcYJFV11kZcFrJvML6jHdvaJaZJQwdnmeN3Tth6JH1yGJhKsPIlQjx5lM+vCOvB5q sDUwL0e261d14keAXdjMIWsHfhsaDW2XFIKXeUSlT6xUafWv1lPV+nTy0A1Gjto88ZRm 4i9FpctTnPaUN+dl2Avcd288uAVTAvUS2CGpCQhYDv3Q1Bau3YYWVz6TAv6OZss8Rg2A oBWD4IPLtSSYVJY1O3UCmPOgrid0jn35geBN40cAGLk2/kgMAEpUcfYoFGpn098ARqm5 +UcQ== MIME-Version: 1.0 X-Received: by 10.220.177.69 with SMTP id bh5mr13496031vcb.22.1366995209160; Fri, 26 Apr 2013 09:53:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 26 Apr 2013 09:53:28 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 12:53:28 -0400 X-Google-Sender-Auth: 6_T1uduq3D_8TpysXFvviwrb5tY Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 16:53:37 -0000 > FWIW, and I do not intend this as a criticism of what you did, I just wen= t back > to the datatracker and looked at the text of the IETF last call. There = is nothing > at all in this text that would indicate that the document said anything a= t all about > the continued use of the SPF DNS RRtype. I've also read the document, a= nd > even reading the conclusion of the document, there's very little there th= at would > suggest to me that the spfbis working group was about to deprecate the us= e of > the SPF DNS RRtype. As Murray's already responded, the intent of the document that became RFC 6686 was simply to report on the SPF/Sender-ID experiment. That document never meant to recommend a specific course, and didn't -- so any cross-area review of that document wouldn't have been likely to raise this discussion, and no text in that document relating to this issue would have been appropriate. That said, there is a general need for chairs, shepherds, and responsible ADs to be aware of these sorts of things. Chairs/shepherds need to make sure something about them gets put into shepherd writeups, at least, and ideally gets sent out to relevant lists earlier. Best I can tell, there *was* a discussion of this earlier, but it didn't get this level of attention. It would also be good for ADs to put things into the last call notices, pointing out things that participants in other areas might want to look at. We don't have a habit of doing that, and we should. Even something like, "This specification involves aspects of [technology X] and [technology Y]; experts in those technologies should pay particular attention and provide reviews and comments," might make a big difference. > On the other side, here are the arguments that I understand to have been = made: > > 1. TXT records are not specific to SPF, thus we can't assume that any giv= en TXT > record is an SPF record. > > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records= are > needed on the names to which SPF TXT records are typically attached. Right: the underscore-prefix technique has been vetted before, and as far as I can tell this issue and its variants are settled. > 3. Using TXT records is a bad idea. > > Rejoinder: this isn't really a technical argument; if there is a technica= l argument > in here, it should be stated explicitly, but this argument per se will be= ignored. Actually, I don't agree that it's not a technical argument. The second part of that sentence is operative, and I want to drill down on that: if there's a technical argument in here, let's tease out what it is. We really have two issues that really seem to matter here: 1. Should we be working on a transition to type=3D99 only, rather than deprecating type=3D99? 2. Claim (quoting M=E5ns here): overloading TXT is bad. (1) is being adequately argued back and forth; I want to focus on (2): Why, specifically, is it bad to use TXT records in an "_spf." subdomain for this purpose? What harm does it cause, specifically. Let's bring that out clearly, and have that part of the discussion, realizing that some possible arguments already have answers: - It's not hard to parse these; there are many parsers out there that work, and there are many text-based protocols that work. - The "_spf." subdomain eliminates the issue of multi-use collisions -- DKIM queries, for example, will go to "_dkim." subdomains, and won't see SPF records in the responses. What other issues does the use of TXT records in this context cause, which would make it clear that migration away from them in SPF is important to avoid damage to the Internet, or at least to the DNS system? Barry From marka@isc.org Fri Apr 26 10:09:59 2013 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 4A36821F9A18; Fri, 26 Apr 2013 10:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nNUgNt6f5Ube; Fri, 26 Apr 2013 10:09:58 -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 35ACD21F99FD; Fri, 26 Apr 2013 10:09:58 -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 731095F991D; Fri, 26 Apr 2013 17:09:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366996197; bh=hHM2pg4wJNMT09QPQMS/InrwcRCiwwhqHNPqQfoNJdE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=CVoYZ/SV0LcvZpH1b6YMd+S0il+CdKAYT0nwGDciFVm5rm2KNXJCsXT0uR7Mmw7DI Yil61LBo8kiAiWZyJG56/aMa8h9LvzEFc+/yWrZmOVy5coEIfTpYS1BjqaYEm4+gaE F3sKwyO76JY6uP2BdPaAt082ItNXIeIxPkESt55o= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 23C6B216C4B; Fri, 26 Apr 2013 17:09:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1DF24331133D; Sat, 27 Apr 2013 03:08:56 +1000 (EST) To: Barry Leiba From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-reply-to: Your message of "Fri, 26 Apr 2013 12:53:28 -0400." Date: Sat, 27 Apr 2013 03:08:56 +1000 Message-Id: <20130426170856.1DF24331133D@drugs.dv.isc.org> Cc: "spfbis@ietf.org" , Pete Resnick , Ted Lemon , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:09:59 -0000 In message , Barry Leiba writes: > > FWIW, and I do not intend this as a criticism of what you did, I just wen= > t back > > to the datatracker and looked at the text of the IETF last call. There = > is nothing > > at all in this text that would indicate that the document said anything a= > t all about > > the continued use of the SPF DNS RRtype. I've also read the document, a= > nd > > even reading the conclusion of the document, there's very little there th= > at would > > suggest to me that the spfbis working group was about to deprecate the us= > e of > > the SPF DNS RRtype. > > As Murray's already responded, the intent of the document that became > RFC 6686 was simply to report on the SPF/Sender-ID experiment. That > document never meant to recommend a specific course, and didn't -- so > any cross-area review of that document wouldn't have been likely to > raise this discussion, and no text in that document relating to this > issue would have been appropriate. > > That said, there is a general need for chairs, shepherds, and > responsible ADs to be aware of these sorts of things. > Chairs/shepherds need to make sure something about them gets put into > shepherd writeups, at least, and ideally gets sent out to relevant > lists earlier. Best I can tell, there *was* a discussion of this > earlier, but it didn't get this level of attention. > > It would also be good for ADs to put things into the last call > notices, pointing out things that participants in other areas might > want to look at. We don't have a habit of doing that, and we should. > Even something like, "This specification involves aspects of > [technology X] and [technology Y]; experts in those technologies > should pay particular attention and provide reviews and comments," > might make a big difference. > > > On the other side, here are the arguments that I understand to have been = > made: > > > > 1. TXT records are not specific to SPF, thus we can't assume that any giv= > en TXT > > record is an SPF record. > > > > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records= > are > > needed on the names to which SPF TXT records are typically attached. > > Right: the underscore-prefix technique has been vetted before, and as > far as I can tell this issue and its variants are settled. > > > 3. Using TXT records is a bad idea. > > > > Rejoinder: this isn't really a technical argument; if there is a technica= > l argument > > in here, it should be stated explicitly, but this argument per se will be= > ignored. > > Actually, I don't agree that it's not a technical argument. The > second part of that sentence is operative, and I want to drill down on > that: if there's a technical argument in here, let's tease out what it > is. > > We really have two issues that really seem to matter here: > > 1. Should we be working on a transition to type=3D99 only, rather than > deprecating type=3D99? > > 2. Claim (quoting M=E5ns here): overloading TXT is bad. > > (1) is being adequately argued back and forth; I want to focus on (2): > > Why, specifically, is it bad to use TXT records in an "_spf." > subdomain for this purpose? What harm does it cause, specifically. > Let's bring that out clearly, and have that part of the discussion, > realizing that some possible arguments already have answers: Wrong question. The correct question is "is the use of _spf bad?". Using a prefix constrains where the solution can be used. It won't work with wildcards. It won't work for all domains. > - It's not hard to parse these; there are many parsers out there that > work, and there are many text-based protocols that work. > > - The "_spf." subdomain eliminates the issue of multi-use collisions > -- DKIM queries, for example, will go to "_dkim." subdomains, and > won't see SPF records in the responses. > > What other issues does the use of TXT records in this context cause, > which would make it clear that migration away from them in SPF is > important to avoid damage to the Internet, or at least to the DNS > system? > > Barry > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Fri Apr 26 10:10:28 2013 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 C0C6721F9A18; Fri, 26 Apr 2013 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, 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 drL44wUMvtD5; Fri, 26 Apr 2013 10:10:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1CA21F99FD; Fri, 26 Apr 2013 10:10:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3QHACCY001747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 10:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366996225; bh=VTusckDU1FnokYWcWxPfBdAYcmcfr8qCOYCAPW1DN5Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=z9ZN8kdlRppat9nrc1O1CXQM523HBr/ikZQxgzMmTchPLJ/xGcV2HZkRQkkbtR/Ld ovGBkDdGhU1ugQmKhf55j8dCuDB1OLHHHSG8ysgo2pse6FvhEfl3Q2+DbPVwcMdnEt ocEvmFnMJASJKtKIqUmB9qyOhdCKHbuvquxbUrEw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366996225; i=@elandsys.com; bh=VTusckDU1FnokYWcWxPfBdAYcmcfr8qCOYCAPW1DN5Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dJ4PdCRJqF0oDXmvcw+WIL2oqwa3MNHUTlmjyfz3FEKTaDfMIKcFelY+yBfe9TQbO X5S4ntfBjHuUMf7hKwSP8bQtARw+4X46C8fzEjDCX6DKQ2dEH0uLUTsmLRg2+y4vtB PbWC7XETqlkClTzuzV2gUSF5dQxK9oJgESsMajD8= Message-Id: <6.2.5.6.2.20130426070324.0c76fc00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 10:09:49 -0700 To: Ted Lemon From: S Moonesamy In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominu m.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Pete Resnick , dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:10:28 -0000 Hi Ted, At 06:41 26-04-2013, Ted Lemon wrote: >[This is really long, because I've spent a lot=20 >of time thinking about this and reading the=20 >discussion; the tl;dr is that I don't intend to=20 >contest the obsoleting of the SPF RRtype any=20 >further, but would not fault others=20 >for doing so, and I think there=20 >are lessons to be learned about how the process=20 >went this time, which, if you are interested=20 >in that, might be a good reason to continue reading.] I'll comment nelow. >I undertook the exercise of reading this thread,=20 >and it looks like there was some very=20 >interesting data collection work done. I=20 >didn't find a point at which a consensus was=20 >determined; I presume that happened later, on some other thread. There are actually several threads about the=20 issue of which RRTYPE to use. The discussions=20 also occurred on unrelated threads. There was an=20 intermediate conclusion (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html=20 ) which was followed by an objection (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html=20 ). The SPFBIS WG Chairs posted a message after=20 that (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html=20 ) which I'll quote partially: "There appears to be a wide variety of opinion about Issue #9. Moreover, the discussion has revealed an=20 interoperability concern in the existing RFC." There was the IETF 83 session (see Item C in the=20 minutes) after that where the SPFBIS Chairs stated the following: "The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99." For what it is worth I edited the minutes by=20 listening to the audio recording. Two drafts of=20 the minutes were posted to the SPFBIS mailing=20 list (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html=20 and=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01419.html=20 ). As there wasn't any objection I considered the issue as resolved. >FWIW, and I do not intend this as a criticism of=20 >what you did, I just went back to the=20 >datatracker and looked at the text of the IETF=20 >last call. There is nothing at all in Let's not worry about that and focus on understanding what happened. :-) > this text that would indicate that the=20 > document said anything at all about the=20 > continued use of the SPF DNS RRtype. I've=20 > also read the document, and even reading the=20 > conclusion of the document, there's very little=20 > there that would suggest to me that the spfbis=20 > working group was about to deprecate the use of the SPF DNS RRtype. Here's an extract from the write-up: "The discussions about the RRTYPE 99 DNS Resource Record were= controversial. The issue was resolved. There was consensus that Sender ID re-use of SPF DNS Resource Records does not have to be called out in the document." I'll highlight one of the points from Section 6 of RFC 6686: "2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it has not attracted enough support to be useful." There is some background information about the=20 RRTYPE in Appendix A of RFC 6686. I agree that the document or even the write-up=20 may not be clear. I left it to Pete Resnick to=20 translate for the IESG. :-) I'll describe the=20 working group climate as unfriendly. It was=20 surprising that was even consensus. >Of course someone who was already involved in=20 >the discussion on the mailing list would know=20 >this, but there's no reason to think that anyone=20 >reading the dnsext mailing list would have felt=20 >it was their duty to review this particular=20 >document during the IETF last call, and if they=20 >had reviewed it, they might still have remained=20 >innocent of any understanding that spfbis=20 >intended to deprecate the SPF RRtype in favor of the TXT record. I expected some people from DNSEXT to raise an=20 issue during the Last Call. There was some text=20 in it which was like asking for trouble. I'll=20 refrain from commenting about DNSEXT reviews. >It seems to me that the argument in favor of=20 >deprecating SPF is that nobody is publishing SPF=20 >records, despite widespread support in=20 >software. This results in unnecessary traffic,=20 >the elimination of which would have minimal impact. Yes. >On the other side, here are the arguments that I understand to have been= made: > >1. TXT records are not specific to SPF, thus we=20 >can't assume that any given TXT record is an SPF record. >Rejoinder: doesn't seem to be an issue in=20 >practice=97no other TXT records are needed on the=20 >names to which SPF TXT records are typically attached. Yes. >2. Because TXT records aren't specific to SPF, a=20 >query for TXT records may return an unexpectedly=20 >large result set, requiring fallback to TCP. >Rejoinder: doesn't seem to be an issue in practice. Yes. >3. Using TXT records is a bad idea. >Rejoinder: this isn't really a technical=20 >argument; if there is a technical argument in=20 >here, it should be stated explicitly, but this argument per se will be= ignored. Probably. :-) >4. Using TXT records sets a bad precedent. >Rejoinder: the horse is already out of the barn. I don't know about this one. >Speaking entirely with my AD hat off, and merely=20 >as an armchair quarterback, I don't think it's=20 >fair to say that the consensus call in spfbis on=20 >what was to become RFC6686 and the IETF=20 >consensus call on that document, taken together,=20 >represent IETF consensus. I don't think the=20 >rejoinders to arguments 1 and 2 are very=20 >convincing, although they seem to have carried=20 >the day in the spfbis working group, and I understand why. It's debatable. I would have to read the=20 detailed arguments to form an opinion. >Having reviewed the discussion in spfbis, and=20 >argued with this at length with Pete, I am=20 >remarkably ambivalent about it. I don't like=20 >the decision the spfbis working group has=20 >made. I don't agree with the decision. I=20 >understand why you made it, and don't fault you=20 >for having made it. It's probably not worth my personal time to dispute= it. At the end of the day a decision has to be=20 taken. It may not be the right decision. There=20 are safeguards in the process if that is the=20 case. I don't mind if anyone disputes the=20 decision. There has been an appeal (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html=20 ). It's part of the work. >I would rather work to hasten the demise of SMTP=20 >and all the anti-spam kludges that rode in on it. :-) > >So, what do I think could have gone better=20 >here? First, it would have been very helpful=20 >if the abstract for RFC 6686 had said that the=20 >reason the research was being done was to answer=20 >the question "should we continue supporting the=20 >SPF RRtype, or drop it?" Authors of drafts=20 >that are trying to address issues like this=20 >might want to think carefully about how they=20 >write abstracts, since it's only the abstract=20 >that gets shown in the IETF last call=20 >message. If your abstract doesn't attract the=20 >people who ought to be reading the document,=20 >it's going to be hard later to argue that the=20 >document had a clear IETF consensus, even though it nominally has= consensus. That sounds like a good idea. >It may be that using the document abstract in=20 >the last call announcement is not sufficient=97if=20 >authors phrased the abstract the way I've=20 >suggested, it might be the wrong thing for the=20 >document once it's published. I don't know the=20 >answer to this=97it might also be the right thing. In the write-up I am supposed to mention whether=20 a draft requires review from a particular or from broader perspective. >I think it's clear that early in this=20 >discussion, all present, including the=20 >responsible AD, were aware that it was going to=20 >be contentious. I think if a message like the=20 >one drc sent to the mailing list yesterday had=20 >gone out in February of 2012, you would have=20 >gotten the exact same response. This probably=20 >would have created additional hassle on the=20 >spfbis mailing list as a bunch of dnsext people=20 >dogpiled there, but we wouldn't be having _this_=20 >conversation _now_, so it actually would have=20 >been better, despite the short-term hassle. With hindsight I'll say that it would have been good to have the discussion. >I hasten to emphasize that I don't really know=20 >what went wrong here. It may be that even if=20 >all the remedies I've discussed above had=20 >happened, we'd still be having a big kerfuffle=20 >about this on the dnsext mailing list. My=20 >motivation for suggesting that more could have=20 >been done is simply my experience as a=20 >participant: I really think I would have=20 >participated in the discussion about this if I'd=20 >realized it was happening last February. I get=20 >the impression from several other participants=20 >in the discussion now that they weren't aware of=20 >it either. I don't have a sense of whether the=20 >discussion would have come out differently if we'd participated. The discussion would have been more=20 controversial. As a rough guess I would say that=20 the Last Call did not work as expected. Some of=20 the reasons for that are mentioned in the (quoted) text above. >And, by the way, internet dating is quite a=20 >lucrative industry, so it's probably a bad example of a hopeless task. :) I might ask the Responsible AD to recharter this=20 working group to work on that task. :-) Regards, S. Moonesamy =20 From hsantos@isdg.net Fri Apr 26 10:10:30 2013 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 1976D21F9A48 for ; Fri, 26 Apr 2013 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.841 X-Spam-Level: X-Spam-Status: No, score=-101.841 tagged_above=-999 required=5 tests=[AWL=0.758, 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 mb+qjNvjsDKN for ; Fri, 26 Apr 2013 10:10:29 -0700 (PDT) Received: from secure.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0D921F99FD for ; Fri, 26 Apr 2013 10:10:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2193; t=1366996222; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=iAphS7R 6p3QGLCd1JaV8rEveK/I=; b=pxPDgv6jnhSbO1Fd7zDQJ87EtOGJHbAc9PDjp1X 9Vm01nyvEyKDf7Yyqk3hGAcEcSicusNxXv0F3WQa1Gj6gYiZsi54O4Fo8JD+j13/ EpJdfc46GBxyLQm3UC9TLYRb8Lf3taB68wEIVimerJJT/lq7fZAELW27vtth8F8Y z4RQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Fri, 26 Apr 2013 13:10:22 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1494943121.1698.5436; Fri, 26 Apr 2013 13:10:21 -0400 Message-ID: <517AB4AD.1090103@isdg.net> Date: Fri, 26 Apr 2013 13:09:01 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <20130425013317.36729.qmail@joyce.lan> <20130426065221.D8E8133032DC@drugs.dv.isc.org> <1638252.lDf4xVkYCO@scott-latitude-e6320> In-Reply-To: <1638252.lDf4xVkYCO@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:10:30 -0000 On 4/26/2013 9:02 AM, Scott Kitterman wrote: > > Since there wasn't the same screaming about DKIM, I wonder if this issue is > really about the RR type at all or if it's really about the design decision on > where to place the record? It seems that SPF is not being penalized in some > form for having gone to the trouble of getting the type assignment and giving > it a go. > In my view, the DKIM decision was entirely based on the fact SPF was getting a huge traction and adoption as a TXT solution. So why not for DKIM? It worked for SPF! We should also note the mindset were among the same authors for protocols that are now entirely TXT: SPF - 99/TXT, Levine against SPF, Murray wasn't around MARID DKIM - TXT only, Murray authored VBR - TXT only, Levine authored DMARK - TXT only, and now a new I-D by Murray SPFBIS - TXT only, Murray started SPFBIS. So we don't have too much "diversity" on the design. SPF goal is still the same design goal for SPF type. The problem are the DNS servers. Getting Microsoft DNS servers to support unnamed RRTYPE processing at the very least will immediately change the course of the RRTYPE needs in the right direction. Its a different problem in the same way AUTH-RES isn't ready for prime time with SPF - an errata is needed and people need to change their Received-SPF reporting. In the mean time, in the name of across the board coding and single-sourcing, you support both even if the AUTH-RES support needs to be done with a kludge comment field. Its the same with DMARC design pressures, it "works" better when MTA does the SPF processing at the 5322 Payload level (DATA state) or you accept the message then do the above tests and it may bounce or perhaps, hopefully not, discard: SPF FAIL POLICY === DKIM/ADSP DISCARD POLICY Ideally, if we are going to stick with TXT based solutions and to better support integrated systems (ones that may support all of the above, it will be at least 4 DNS TXT queries), then we explore a direct solution of a single call to return all the sender information one may need about, including the message owner and copyright holder domain. -- HLS From warren@kumari.net Fri Apr 26 10:29:35 2013 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 A2DC721F9731 for ; Fri, 26 Apr 2013 10:29:34 -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 8kvR70JmD25Y for ; Fri, 26 Apr 2013 10:29:33 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9968121F9653 for ; Fri, 26 Apr 2013 10:29:33 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 89B5B1B40206; Fri, 26 Apr 2013 13:29:32 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <20130426041132.D7D7C32FE54F@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 13:29:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D672139-E652-4A46-8AA2-077CC5A7D1DB@kumari.net> References: <20130426034321.68173.qmail@joyce.lan> <20130426041132.D7D7C32FE54F@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 17:29:35 -0000 On Apr 26, 2013, at 12:11 AM, Mark Andrews wrote: >=20 > In message <20130426034321.68173.qmail@joyce.lan>, "John Levine" = writes: >>>> 1. Insert the ability into the interface to add freeform stuff >>>> 2. Run the equivalent of named-checkzone prior to committing the = change >>>> 3. Profit! >>=20 >> I don't know whether to laugh or cry. >>=20 >> No, this won't work with provisioning systems in the real world, that >> have to be usable by people who are not DNS weenies, and work in >> systems where the software upgrade cycle is months or years, not = days. +1 >>=20 >> There are real reasons that seven years after RFC 4408, most >> provisioning systems still don't handle type 99 records, and it's not >> because everyone who does e-mail is stupid. >=20 Yup. And even many of the ones that *do* support type 99 don't allow = adding arbitrary types. I use GoDaddy as a registrar (never underestimate the power of apathy = :-)). I just changed a test domain to use their hosted DNS solution. I can add any of the following though the web interface: A (Host) CNAME (Alias) MX (Mail Exchanger) TXT (Text) SPF (Sender Policy Framework) SRV (Service) AAAA (IPv6 Host) NS (Nameserver) (I wasn't actually expecting them to support SPF, but they do (and even = have a reasonable interface for it). Pleasant, if pointless, surprise). But, there is no way (that I've found) to add other record types (like = TLSA or SSHFP or=85). [There was some "Premium DNS" option that I didn't = try (see the apathy comment) -- maybe it does it?] There is an "Export.." and "Import=85" option. Lets try that=85 Export the current zone file... Add "test 3600 IN TYPE65530 \# 1 ( 42 )" Click Import. Fails with "Invalid file". Ok, maybe something a little = less unusual=85 Try SSHFP. No love. Try TLSA. No love. I get why they don't allow arbitrary types (it costs a little more, very = few of their customers need it, there is some (small) security risk, = some customer will enter "Bob" in a type-17 record and then wonder why = Bob isn't suddenly responsible, etc), but it does make me sad=85 Unfortunately I don't really see a way to change this -- most registrars = are incentivized to provide what the majority of the customers want for = the minimum cost. My auntie won't choose a different registrar because = her current one doesn't support NAPTR=85 (It looks like Dyn may support arbitrary record types = (http://dyn.com/support/record-types-standard-dns/), but I'm not 100% = sure. See the apathy comment again) > It just money. Really that is the only reason at this point. =20 Yup[0], but saying "Its just money" in this context is like saying you = can solve world hunger by "Just giving everyone more food" -- while = true, it's not particularly helpful. > They > won't spend a cent to make their systems updatable or they want to > charge extra for supporting type 99 records. Yup.=20 >=20 >> No need to respond, you've made your point, although it may not be >> what you thought it was. >=20 > One can upgrade components of a system. Nameservers are regularly > upgraded independently on the rest of the system. Similarly > other tools are regularly upgraded. W. [0]: Actually I wouldn't say that it is only money -- there is also the = concern about customers shooting themselves in the foot, and then you = having to help them recover, time, priorities, keeping a clean UI, etc. >=20 >> R's, >> John >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 --=20 "I think it would be a good idea."=20 - Mahatma Ghandi, when asked what he thought of Western civilization From paf@frobbit.se Fri Apr 26 11:01:02 2013 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 DF87021F99DA; Fri, 26 Apr 2013 11:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FN-CzdIkUGa; Fri, 26 Apr 2013 11:01:01 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C921F99C2; Fri, 26 Apr 2013 11:00:55 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::f160:8e06:3c06:258e] (unknown [IPv6:2a02:80:3ffc:0:f160:8e06:3c06:258e]) by mail.frobbit.se (Postfix) with ESMTPSA id 2A2D021DE9; Fri, 26 Apr 2013 20:00:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130426170856.1DF24331133D@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 20:00:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2122D2D2-70A8-4EFA-B4E1-1D9F6E0A728E@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <20130426170856.1DF24331133D@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) Cc: "spfbis@ietf.org" , Pete Resnick , Barry Leiba , Ted Lemon , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:01:02 -0000 On 26 apr 2013, at 19:08, Mark Andrews wrote: > Using a prefix constrains where the solution can be used. It won't > work with wildcards. It won't work for all domains. There CAN be a zone cut between the SPF record and the MX, which in turn = might have impact on trust related to DNSSEC. I have no idea on the implications, but I do not see it being examined. Patrik From dougb@dougbarton.us Fri Apr 26 11:01:30 2013 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 ABC5721F99E1 for ; Fri, 26 Apr 2013 11:01:30 -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 mTsIV+5D+X6l for ; Fri, 26 Apr 2013 11:01:30 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE3BB21F99CA for ; Fri, 26 Apr 2013 11:01:29 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c] (unknown [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c]) by dougbarton.us (Postfix) with ESMTPSA id 7D4B322BA5 for ; Fri, 26 Apr 2013 18:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366999289; bh=yoj6eHMJgkOh8yVXL/2lvy+nETEthz93kZ4d1urxLiY=; h=Date:From:To:Subject:References:In-Reply-To; b=e8gJNq2WzO5A88VN5l1i+SZtQE5F9C2WcDpuSusGVu7nBEKhfjnrI9VT325ZF8i3/ l8+qAWuS7PtGHAYxkE1xGNSaWxavCPn3ZcgzxYJH77obgE+fHIIZUmWjcoTNSHMRn5 HN0bIJXHIFJhE5Vl+Whm9KcyFDz9coLGNNe0LflU= Message-ID: <517AC0F9.8040209@dougbarton.us> Date: Fri, 26 Apr 2013 11:01:29 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130426004632.B5E1E32FAF70@drugs.dv.isc.org> <5179DB4B.2040403@dougbarton.us> <20130426121424.GA349@mx1.yitter.info> In-Reply-To: <20130426121424.GA349@mx1.yitter.info> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 18:01:30 -0000 On 04/26/2013 05:14 AM, Andrew Sullivan wrote: > I am speaking here as an individual and as an operator. > > On Thu, Apr 25, 2013 at 06:41:31PM -0700, Doug Barton wrote: > >> 1. Insert the ability into the interface to add freeform stuff >> 2. Run the equivalent of named-checkzone prior to committing the change >> 3. Profit! > > That's preposterously naive. Careful, that's dangerously close to ad hominem. :) > Step 2.1 is "Find that customer who has > no theory of the mystifying DNS arcana screwed it up, so you can't > publish, and now you have to contact a human. No, you don't. You write the documentation in advance about how the known type codes work, and when the thing fails you send them to a page that says, "I think you meant to do 'this' which should look like 'that.' If that's not what you wanted, go 'here' which has a big list o' DNS records and their proper format." Not to throw resumes around or anything, but I used to be in that business. I've written management platforms for DNS. When I left Yahoo! we had over 600,000 domains in our registrar-reseller business. My current business is enterprise DNS/DHCP/IPAM management solutions. Prior to that I was working for a company that does hosted solutions for mom and pop's all the way up to major e-commerce sites. I'm not talking out of my ass here, I'm explaining that there is a real solution to this problem. The real issue (as you point out below) is that it isn't free, in either sense (speech or beer). > Stop. Invoke expensive > off-page customer service process." In some significant number of > cases, we never get to step 3. In the DNS business, the margins are > small. Thank you for confirming the real problem, which as I have pointed out in the past, is that the operators, especially hosting providers that cater to naive users, don't want to make ANY changes because it costs money on both the front and the back ends. > This list -- and indeed, much of the IETF, as is often lamented -- is > heavily populated by people who either are not operators or else are > not consumer-facing operators, though there are notable exceptions. > It sseems at least possible that this introduces a bias of ignoring > problems that others report (or that are observable in deployment) > because they're not the problems of the people who happen to be here. > > I have to agree with John Levine that the usual answer of the DNS > community to provisioning problems -- in caricature, "This is easy, > you must be morons." -- is not helpful, and is indicative of a closed > mindedness that is unbecoming. I'm not close-minded, and I'm not naive. I'm also not willing to allow all progress on new DNS type codes to be held hostage to providers unwilling to invest in their own infrastructure. Doug From ajs@anvilwalrusden.com Fri Apr 26 11:04:13 2013 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 3B39421F99C2 for ; Fri, 26 Apr 2013 11:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nM-7fPmbaB4 for ; Fri, 26 Apr 2013 11:04:12 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55621F9946 for ; Fri, 26 Apr 2013 11:04:12 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F3DB58A031 for ; Fri, 26 Apr 2013 18:04:11 +0000 (UTC) Date: Fri, 26 Apr 2013 14:04:07 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130426180406.GA750@mx1.yitter.info> References: <20130426034321.68173.qmail@joyce.lan> <20130426041132.D7D7C32FE54F@drugs.dv.isc.org> <4D672139-E652-4A46-8AA2-077CC5A7D1DB@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D672139-E652-4A46-8AA2-077CC5A7D1DB@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 18:04:13 -0000 On Fri, Apr 26, 2013 at 01:29:32PM -0400, Warren Kumari wrote: > (It looks like Dyn may support arbitrary record types (http://dyn.com/support/record-types-standard-dns/), but I'm not 100% sure. See the apathy comment again) > Nope, we don't. Last I checked, also, GoDaddy actually _published_ the SPF records you send them as a TXT, but I haven't checked recently. That's what Dyn tells you to do in the "Standard DNS" product. Our enterprise product (DynECT DNS) offers the TYPE 99, partly because that product involves access to our concierge people, who can help you out when things go wrong. The low-price Standard offering is only possible to offer if our support costs are kept low, which means "no hand-holding". Because we're interested in a good customer experience, we have to be conservative about what we offer. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Ted.Lemon@nominum.com Fri Apr 26 11:42:08 2013 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 66CE221F985F; Fri, 26 Apr 2013 11:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 B4B4i2dOS40o; Fri, 26 Apr 2013 11:42:08 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C136221F9579; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrKf5dP1eZ1hFJHYqJesJXfjAlUeHln@postini.com; Fri, 26 Apr 2013 11:42:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 43A6A1B80E6; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B75C190061; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 11:42:07 -0700 From: Ted Lemon To: Barry Leiba Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qA Date: Fri, 26 Apr 2013 18:42:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41AE2352D5BCD14B8E56812D805FD5CE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:42:08 -0000 On Apr 26, 2013, at 12:53 PM, Barry Leiba wrote: > It would also be good for ADs to put things into the last call > notices, pointing out things that participants in other areas might > want to look at. We don't have a habit of doing that, and we should. > Even something like, "This specification involves aspects of > [technology X] and [technology Y]; experts in those technologies > should pay particular attention and provide reviews and comments," > might make a big difference. Yes. > Why, specifically, is it bad to use TXT records in an "_spf." > subdomain for this purpose? What harm does it cause, specifically. > Let's bring that out clearly, and have that part of the discussion, > realizing that some possible arguments already have answers: I think it's mostly harmless, but it's not what 4408bis does. From dougb@dougbarton.us Fri Apr 26 12:31:39 2013 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 1803B21F99BC; Fri, 26 Apr 2013 12:31:39 -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 bz2yY1YBUjSs; Fri, 26 Apr 2013 12:31:38 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2256B21F99BA; Fri, 26 Apr 2013 12:31:38 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c] (unknown [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c]) by dougbarton.us (Postfix) with ESMTPSA id C3EAC22B11; Fri, 26 Apr 2013 19:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367004697; bh=6H15Mw1ssOq7L2ZKPTtmjntMxzzF9yUXtSicA7tehbw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=HdPGtalgzD0TXyB/picgV7ROq3Vb8URajpG3UaA4zozMB+HsoW9OTB66CE5XTtM3D RiqnRskDZwByQ++BsGxNMy+3wrUfsH/fhLfA7SKT/ME7CKoQewbXrHPVcXdmxA87Ka cPKmnbFnXZZ2DmD9abbkMRqCYBc8LC2uIthecJ8Y= Message-ID: <517AD619.3000406@dougbarton.us> Date: Fri, 26 Apr 2013 12:31:37 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:31:39 -0000 On 04/25/2013 11:30 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 11:05 PM, David Conrad > wrote: > > > So how much energy are the DNS experts going to put into cleaning > up their house while demanding the mail people clean up theirs? > > So, this is about revenge because it used to be hard to get RRtypes? > > > Did I really come across as that petty? Uncharitable interpretation of the current situation could come to that conclusion. > No, what I'm saying is that the way things were ten years ago As I (and others) have said many times, things were rough at the time SPF came to bloom. However, and this is really important to understand, it's not 10 years ago anymore. I'm not being petty when I say that. It really is important to understand, the time is going to pass anyway. In the time period between then and now a LOT of things have happened in the DNS world, and the situation is dramatically different now than it was. What is even more important to understand is that 10 years from now 10 more years will have passed. We have a chance now to set in motion events that will continue to improve the situation, so that 10 years from now we can look back and laugh at the SPF TXT record, and have joy that things are so much better. Or, we can spend 10 more years with the same silly kludge, and not have made any progress at all. Either way, the next 10 years are going to pass. > pushed the > SPF community to the place it's in now, ugly as it is. SPF, in the > interim, has become very widely deployed. And some of the software that handles SPF has already switched to querying SPF/99 first. There is no reason that the rest could not do that as well. Then by the time that the next version of SPF is released, it can be all SPF/99, and no TXT. Eventually the TXT record will die out altogether. As I have mentioned previously, in the DNS world we have a LOT of experience dealing with issues EXACTLY like this. We know how it works, we know what long tails look like, and we know that as problems go it's a pretty easy problem to deal with. > Suddenly now we have a few > voices from the ivory tower asserting that the same community needs to > go out and re-do things the way they should have been done in the first > place, now that we finally have a somewhat more reasonable perspective, > even though some of the vestiges of ten years ago are in fact still > around. My reaction to that is "You can't be serious." That doesn't > sound like revenge at all to me, just pragmatism. Um, it's not "suddenly." The advice to do it right in the first place has been offered repeatedly, since the very beginning. That's why the code point was assigned in the first place. There is no doubt that in the early days, prior to the widespread deployment of 3597, querying for SPF/99 could cause problems. But we're not in that world anymore. Thank DNSSEC and IPv6 for shaking things loose. There is currently no TECHNICAL reason that the change cannot be made NOW to query SPF/99 first. The only argument you (and others) have put forward so far is, "We have been using TXT, it works, so we want to keep using it." I understand why that course of action is attractive, but it's bad. And the right thing isn't hard to do. > The point is that it isn't just fine. It does have operational > impacts, from potentially increased fragmentation/fallback to TCP to > increased complexity in TXT RR parsers that have to distinguish > between the myriad of crap that's residing at the zone apex TXT RR, > etc. Of course, most of these negative impacts are hidden to the > folks who are putting the TXT RRs in the zone, so it's all good, right? > > > Thus, I maintain that we take our licks on this one and just take > steps to ensure that nobody follows this path again. > > And how do you propose that exactly, particularly given the > precedent set by SPFBIS? > > > Someone else (Joe, I think) has already referred to other RFCs that talk > about things like IAB advice about how [not] to put application data > into the DNS. Seems to me this is a perfectly good subject for another > such project. One may counter that by saying nobody will pay attention > to such a document, but I submit that it's our primary mechanism for > making sure mistakes aren't re-made, so that's the tool we have to use > or not use. But this mistake isn't carved in stone. It CAN be fixed. And the solution isn't difficult. Some minor changes are made to software, some docs are updated, and then time passes and the old way becomes obsolete. > If we do the opposite and somehow compel SPFBIS to favour type 99 over > TXT, then I still think we'll be shouting that to an audience that will > think we're nuts and simply go about their business. If that happens (and I personally don't think it will), it's not the IETF's problem. We don't (traditionally) write specs to accommodate the worst behavior we see in implementations. We write specs to describe how it should be done right, and do our best to support people who want to write software that does it right. And I should emphasize again, "Mail::SPF (which is used by Spamassassin) checks for Type SPF first by default." So there is already a non-trivial implementation that is doing it right. The number of other implementations that need to be updated is not very large. Another case mentioned in the spfbis thread on "issue #9" was the python lib for spf, which already has the code to query SPF/99. It would be a 30 minute job to update that to query 99 first. So if I'm missing some TECHNICAL reasons why this proposal isn't feasible, please enlighten me. But all I've seen so far is, "We don't want to do it," which I don't find particularly compelling. Doug From dhc2@dcrocker.net Fri Apr 26 13:44:00 2013 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 C112A21F9954; Fri, 26 Apr 2013 13:43:59 -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 hPQYMOPs+BHV; Fri, 26 Apr 2013 13:43:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16DDE21F962B; Fri, 26 Apr 2013 13:43:59 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3QKhtCF019402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 13:43:58 -0700 Message-ID: <517AE707.4000206@dcrocker.net> Date: Fri, 26 Apr 2013 13:43:51 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 26 Apr 2013 13:43:58 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:44:00 -0000 On 4/23/2013 3:03 PM, S Moonesamy wrote: > Hello, > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > Is the annotation in the DNS Parameters registry correct? Dear DNSEXT, For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked. DNSEXT was asked to provide expert review of this specific bit of text. The text is intended to be comparable to the way that some other, similar situations have already been handled. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From drc@virtualized.org Fri Apr 26 13:55:19 2013 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 3F8D821F986C; Fri, 26 Apr 2013 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Y+b-msTPoZ4e; Fri, 26 Apr 2013 13:55:09 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6F21F9855; Fri, 26 Apr 2013 13:55:02 -0700 (PDT) Received: from [172.20.1.101] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 6224017166; Fri, 26 Apr 2013 20:55:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <517AE707.4000206@dcrocker.net> Date: Fri, 26 Apr 2013 15:55:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:55:19 -0000 Dave, As I pointed out to Paul Hoffman, the message I sent that I believe = started this thread said: "It is in keeping with past practice, e.g., see the notations for MD, = MF, A6, and the MAILA RRtypes at = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml." Regards, -drc On Apr 26, 2013, at 3:43 PM, Dave Crocker wrote: > On 4/23/2013 3:03 PM, S Moonesamy wrote: >> Hello, >>=20 >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF = RRTYPE: >>=20 >> 'IANA is requested to add an annotation to the SPF RRTYPE saying >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >>=20 >> Is the annotation in the DNS Parameters registry correct? >=20 >=20 > Dear DNSEXT, >=20 > For all of the really interesting side discussions that have developed = since SM sent this initial query, I believe there have not been any = responses that answered the question that was asked. >=20 > DNSEXT was asked to provide expert review of this specific bit of = text. The text is intended to be comparable to the way that some other, = similar situations have already been handled. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From dhc2@dcrocker.net Fri Apr 26 14:04:02 2013 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 3A15521F98B0; Fri, 26 Apr 2013 14:04:02 -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 Rdtq+2PaGcC9; Fri, 26 Apr 2013 14:04:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7284421F9897; Fri, 26 Apr 2013 14:04:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3QL3vD3019796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 14:04:00 -0700 Message-ID: <517AEBB8.3090105@dcrocker.net> Date: Fri, 26 Apr 2013 14:03:52 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Conrad References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> In-Reply-To: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 26 Apr 2013 14:04:00 -0700 (PDT) Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:04:02 -0000 On 4/26/2013 1:55 PM, David Conrad wrote: > Dave, > > As I pointed out to Paul Hoffman, the message I sent that I believe > started this thread said: > > "It is in keeping with past practice, e.g., see the notations for MD, ahh. right. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Fri Apr 26 14:50:31 2013 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 67C9D21F9CF2 for ; Fri, 26 Apr 2013 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 L7h05muB1Z5A for ; Fri, 26 Apr 2013 14:50:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id ED97E21F9CEB for ; Fri, 26 Apr 2013 14:50:29 -0700 (PDT) Received: (qmail 66223 invoked from network); 26 Apr 2013 21:50:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2013 21:50:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517af69a.xn--9vv.k1304; i=johnl@user.iecc.com; bh=ZcVqatb2TCZAK9E3ws8ik9HGGUlAqAVeociILZzCuF0=; b=b6slyj2eqpDazQrLYjfeJ4BGT+XukWhAWZZK/pBoL7UWp7FlSenw19xs/rn4CpqZyi8HPq+1Q2K5vlcyIIM/0TXmTEqx38lLK1Rx2uEVDOtXzjlmy02+MsYLDyYKXf6HwzA6KgOGG5UPgYRZuW+EfHckSMP7BM3qIOEiEAYnjbY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517af69a.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=ZcVqatb2TCZAK9E3ws8ik9HGGUlAqAVeociILZzCuF0=; b=1QCd0pIuUG3HKGuZMB2z1iszC3m5rsJ4YawxntUxBPWbcTrM0OROEDmkekJu6OasxR6yRYfIeXZclCG7IEmIIbjZfv/lqa2EZGHyUPEvSEPPRKoR8RNkJ4x7uOGOCH7PnmQZMJKHRAYABmw9DSmgP2WsBvDFjvFRHnlr590XDZQ= Date: 26 Apr 2013 21:49:56 -0000 Message-ID: <20130426214956.75110.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:50:31 -0000 >Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF community a good lesson. (Seriously?) This may come as a surprise, but this isn't all about you. The spfbis group is cleaning up a protocol that is in use at hundreds of thousands of mail systems all over the world including most, probably all, of the largest ones. For all its warts, SPF works fine as is, and they have no incentive to change. Hence the narrow charter of the group only to clean up the existing spec, not to extend or change it. I go to a industry meetings like MAAWG with all of the large mail operators, and I can assure you that if the IETF were so silly as to publish an spfbis that demanded a switch to type 99, the large mail systems would say, wow, that was dumb, I guess we'll be looking for mail standards somewhere else. >> Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows >this path again. > >And how do you propose that exactly, particularly given the precedent set by SPFBIS? Provide the tools and processes so that people can use new RRTYPEs in new designs. (Insert usual point about provisioning.) Don't shoot yourself in the foot by demanding that we break one that's a decade old and likely in wider use than 95% of all of the other IETF protocols. R's, John From superuser@gmail.com Fri Apr 26 14:59:01 2013 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 9C12721F99AA; Fri, 26 Apr 2013 14:59:01 -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, HTML_MESSAGE=0.001, 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 ba6-vJgK4T+6; Fri, 26 Apr 2013 14:59:00 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1421F998B; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1093248wib.17 for ; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jmOwnbaZpz0gnH1v55Y3Il2SO0jBL6sigCSh7DV/Pes=; b=VxpEIM0iyp9t2IK8cgcjMQ2G0oEJ3cVnR9YmuQZxawjS2tPNgQpzRycmpl5x2BYY1V ku3VacT3hslhhqn7xbdTHfMchS885dRB5gy9VNIKyLf9pVGg/lfy9o+VNyv8Z5kO9RDZ bLNaydTQfxDkPpjKb4IogY7BD+0dAm/GNsQkZ4oA0itzGiqmeBFOzl7Uz1Rnjl+iSyOy PYGaIszmsr7/EBWEU001QAvxQrpmItaE/9URa4wwD/0NRtn92ekYQpb2fqZNUm3xijZy Dw+5QWE3AZJj2Rzr0717zP8JwzoOytR6JcNYqdp1GjmzWxgkuMYjzNtAU9WaaQc9+26h LQWg== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr6414418wic.32.1367013539292; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) In-Reply-To: <517AD619.3000406@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <517AD619.3000406@dougbarton.us> Date: Fri, 26 Apr 2013 14:58:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=001a11c3483069abe404db4aa437 Cc: "spfbis@ietf.org" , "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:59:02 -0000 --001a11c3483069abe404db4aa437 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton wrote: > > No, what I'm saying is that the way things were ten years ago >> > > As I (and others) have said many times, things were rough at the time SPF > came to bloom. However, and this is really important to understand, it's > not 10 years ago anymore. > I am keenly aware of the date. What I am also keenly aware of, as I (and others) have said many times, is that SPF set off in a specific direction based on the situation ten years ago and has continued in that direction all this time. Now, with the situation "at home" largely-but-not-completely improved, there are a few people now exclaiming that it went in the wrong direction, and that needs to be fixed. It's very easy to make that assertion when one ignores questions of momentum and inertia. I'm not being petty when I say that. It really is important to understand, > the time is going to pass anyway. In the time period between then and now a > LOT of things have happened in the DNS world, and the situation is > dramatically different now than it was. > Nobody's arguing that point. > > What is even more important to understand is that 10 years from now 10 > more years will have passed. We have a chance now to set in motion events > that will continue to improve the situation, so that 10 years from now we > can look back and laugh at the SPF TXT record, and have joy that things are > so much better. Or, we can spend 10 more years with the same silly kludge, > and not have made any progress at all. Either way, the next 10 years are > going to pass. Sure. Is that a good use of engineering resources? This is where we appear to differ. I claim, given current data, that it is not. > > And some of the software that handles SPF has already switched to querying > SPF/99 first. There is no reason that the rest could not do that as well. I agree with the first sentence, but not the second. > As I have mentioned previously, in the DNS world we have a LOT of > experience dealing with issues EXACTLY like this. We know how it works, we > know what long tails look like, and we know that as problems go it's a > pretty easy problem to deal with. > This situation touches more than just DNS code. You appear to be convinced that the path to overcoming inertia in the DNS world is the same, or maybe even harder, than it is in other environments like email. I am not a believer. > > Um, it's not "suddenly." The advice to do it right in the first place has > been offered repeatedly, since the very beginning. That's why the code > point was assigned in the first place. > Um, it is "suddenly", or have you a copy of the spfbis archive that's different from the one I have? > > There is no doubt that in the early days, prior to the widespread > deployment of 3597, querying for SPF/99 could cause problems. But we're not > in that world anymore. Thank DNSSEC and IPv6 for shaking things loose. > There is currently no TECHNICAL reason that the change cannot be made NOW > to query SPF/99 first. The only argument you (and others) have put forward > so far is, "We have been using TXT, it works, so we want to keep using it." > I understand why that course of action is attractive, but it's bad. And the > right thing isn't hard to do. > I'm sorry, but that is not the only argument I (and others) have put forward so far. If this conversation is going to be selective in that manner, then I think I'm done here. -MSK --001a11c3483069abe404db4aa437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton <dougb@do= ugbarton.us> wrote:

No, what I'm saying is that the way things were ten years ago

As I (and others) have said many times, things were rough at the time SPF c= ame to bloom. However, and this is really important to understand, it's= not 10 years ago anymore.

I am keenly = aware of the date.=A0 What I am also keenly aware of, as I (and others) hav= e said many times, is that SPF set off in a specific direction based on the= situation ten years ago and has continued in that direction all this time.= =A0 Now, with the situation "at home" largely-but-not-completely = improved, there are a few people now exclaiming that it went in the wrong d= irection, and that needs to be fixed.

It's very easy to make that assertion when one ignores questions of= momentum and inertia.


I'm not being petty when I say that. It really is important to understa= nd, the time is going to pass anyway. In the time period between then and n= ow a LOT of things have happened in the DNS world, and the situation is dra= matically different now than it was.

Nobody's arguing that point.
=A0

What is even more important to understand is that 10 years from now 10 more= years will have passed. We have a chance now to set in motion events that = will continue to improve the situation, so that 10 years from now we can lo= ok back and laugh at the SPF TXT record, and have joy that things are so mu= ch better. Or, we can spend 10 more years with the same silly kludge, and n= ot have made any progress at all. Either way, the next 10 years are going t= o pass.

Sure.=A0 Is that a good use of engineering resources?= =A0 This is where we appear to differ.=A0 I claim, given current data, that= it is not.
=A0

And some of the software that handles SPF has already switched to querying = SPF/99 first. There is no reason that the rest could not do that as well. <= /blockquote>

I agree with the first sentence, but not th= e second.
=A0
As I have mentioned previously,= in the DNS world we have a LOT of experience dealing with issues EXACTLY l= ike this. We know how it works, we know what long tails look like, and we k= now that as problems go it's a pretty easy problem to deal with.

This situation touches more than just DNS = code.=A0 You appear to be convinced that the path to overcoming inertia in = the DNS world is the same, or maybe even harder, than it is in other enviro= nments like email.=A0 I am not a believer.
=A0

Um, it's not "suddenly." The advice to do it right in the fir= st place has been offered repeatedly, since the very beginning. That's = why the code point was assigned in the first place.

Um, it is "suddenly", or have you a copy of the sp= fbis archive that's different from the one I have?
=A0

There is no doubt that in the early days, prior to the widespread deploymen= t of 3597, querying for SPF/99 could cause problems. But we're not in t= hat world anymore. Thank DNSSEC and IPv6 for shaking things loose. There is= currently no TECHNICAL reason that the change cannot be made NOW to query = SPF/99 first. The only argument you (and others) have put forward so far is= , "We have been using TXT, it works, so we want to keep using it."= ; I understand why that course of action is attractive, but it's bad. A= nd the right thing isn't hard to do.

I'm sorry, but that is not the only ar= gument I (and others) have put forward so far.=A0 If this conversation is g= oing to be selective in that manner, then I think I'm done here.
-MSK
--001a11c3483069abe404db4aa437-- From marka@isc.org Fri Apr 26 15:46:14 2013 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 90DEB21F99B6 for ; Fri, 26 Apr 2013 15:46: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 jB7DxFNdLPfk for ; Fri, 26 Apr 2013 15:46:13 -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 C406D21F97D9 for ; Fri, 26 Apr 2013 15:46:13 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 51DC1C9427; Fri, 26 Apr 2013 22:46:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367016373; bh=DeLQXAYOguM28cmE5/gyIHYdsl8hJ3amTEv54coyW1w=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=jlqKc5auBRUfvAmf9ObyESa3cPW241aS3Dlgi4rm8zDW2JwxAfpVAxQw8iu7HgYGK 5yMvFkTyGj3pkluEmCQW7ljFE2tZgTkeJucjB5TikEuyHoEQnnt05rSyH/Wk0YSAno aVXuSYThF0cthJdY40NV7/pb6wrcQVypPkMfX/68= 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; Fri, 26 Apr 2013 22:46:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 04496216C40; Fri, 26 Apr 2013 22:46:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C289A331351F; Sat, 27 Apr 2013 08:45:53 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130426214956.75110.qmail@joyce.lan> In-reply-to: Your message of "26 Apr 2013 21:49:56 +0000." <20130426214956.75110.qmail@joyce.lan> Date: Sat, 27 Apr 2013 08:45:53 +1000 Message-Id: <20130426224553.C289A331351F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:46:14 -0000 In message <20130426214956.75110.qmail@joyce.lan>, "John Levine" writes: > >Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF community a good lesson. (Seriously?) > > This may come as a surprise, but this isn't all about you. > > The spfbis group is cleaning up a protocol that is in use at hundreds > of thousands of mail systems all over the world including most, > probably all, of the largest ones. For all its warts, SPF works fine > as is, and they have no incentive to change. Hence the narrow charter > of the group only to clean up the existing spec, not to extend or > change it. > > I go to a industry meetings like MAAWG with all of the large mail > operators, and I can assure you that if the IETF were so silly as to > publish an spfbis that demanded a switch to type 99, the large mail > systems would say, wow, that was dumb, I guess we'll be looking for > mail standards somewhere else. > > >> Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows > >this path again. > > > >And how do you propose that exactly, particularly given the precedent set by SPFBIS? > > Provide the tools and processes so that people can use new RRTYPEs in > new designs. (Insert usual point about provisioning.) > > Don't shoot yourself in the foot by demanding that we break one that's > a decade old and likely in wider use than 95% of all of the other IETF > protocols. As far as I can see no one is asking anyone to break SPF. All they are asking is to let it continue down the path towards all type SPF. The DNS people know that will take years before people will feel comfortable with using SPF only. MX only domains took years as well before people were confident to use them. Instead of going for deprecation ask nameserver vendors to add automatic insertion of type SPF if there is no SPF RRset (SHOULD level). This will help sites that are unintentionally breaking the SHOULD publish both records. Note most of the sites that described how to do SPF failed to mention that you are supposed to publish both which where generally written by people trying to promote SPF. e.g. http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ That includes sites written by people in the SPF working group who should have known better. When every example is a single TXT record it is hardly suprising that type SPF was not being published often. Conspiracy theorists would say that it was a deliberate attempt to undermine type SPF. > R's, > John > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Fri Apr 26 16:14:54 2013 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 5C63F21F9D15 for ; Fri, 26 Apr 2013 16:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.874 X-Spam-Level: X-Spam-Status: No, score=-110.874 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 qf+pZYKzUV6P for ; Fri, 26 Apr 2013 16:14:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC221F9D0D for ; Fri, 26 Apr 2013 16:14:53 -0700 (PDT) Received: (qmail 84239 invoked from network); 26 Apr 2013 23:14:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2013 23:14:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517b0a6c.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=BDjkOMNkY9GF95J6Ii8Jjxkk8rSh8mehA8jgEgq0U5g=; b=FaCP0Df8D5admtIfViA6NGHzYmhb9DnX6K1wk6GLd3hqA6b/yUAd3qgsUrmYqNW7PxeGWZ94yrHmyblEQZJ6WBKIN7zWo3+CIEu28Luqf7fFVfLtcFQr3sy2+yexEzxkfacqS/Xz0VNNkoJL1WoC/ggCbf09mudhHRQ9mUdmDuY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517b0a6c.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=BDjkOMNkY9GF95J6Ii8Jjxkk8rSh8mehA8jgEgq0U5g=; b=01NNbZlr7FJXffKLxpmRzAylRcJ8ChJCiVZUwg5/pCEIBnOS8/BKRlQPrNo3VSkjhFSzKQcfEN2WaMYMoc0dIDSXvZ8IRiqRPPEA/+Pd0wxj+R1uHcSEhreorm3o9p2fTpt+XvQISoIi8bXFe1aMXheWt1JkFHVrjzEiTyIH7LU= Date: 26 Apr 2013 23:14:30 -0000 Message-ID: <20130426231430.75437.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130426121424.GA349@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 26 Apr 2013 23:14:54 -0000 >On Thu, Apr 25, 2013 at 06:41:31PM -0700, Doug Barton wrote: > >> 1. Insert the ability into the interface to add freeform stuff >> 2. Run the equivalent of named-checkzone prior to committing the change >> 3. Profit! > >That's preposterously naive. Step 2.1 is "Find that customer who has >no theory of the mystifying DNS arcana screwed it up, so you can't >publish, and now you have to contact a human. Stop. Invoke expensive >off-page customer service process." In some significant number of >cases, we never get to step 3. In the DNS business, the margins are >small. You also forgot step 1.9, in which the software faeries magically update named-checkzone for every new RRTYPE, even though the times when new RRTYPEs are defined bear no relation to any sort of software update or release schedule, and people who want to experiment with new RRTYPEs are unlikely also to have the skills or inclination to patch the BIND parser. R's, John PS: That's why my hack, using an idea from Vixie, automatically configures new RRTYPEs as they're published, with no software changes or updates needed. Again, I don't claim that's the only way to do it, but I do strongly believe that a useful configurable provisioning or DNS system can't require per-RR software changes. From doug.mtview@gmail.com Fri Apr 26 17:15:34 2013 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 248C221F9636 for ; Fri, 26 Apr 2013 17:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 dgSvKXJuUVdO for ; Fri, 26 Apr 2013 17:15:33 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7893A21F962E for ; Fri, 26 Apr 2013 17:15:33 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp18so3984398obc.20 for ; Fri, 26 Apr 2013 17:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=VSMaQ7B/zwHXT0CnZYVoP/dmRiOzY9lT0IG62nvUSKA=; b=rmDn5CkOavlua41CjQCR3bASPkebedasIyOWsiFGwgSd5Zp09gABWPpS2tVoN8Tynb u6g0WxGqA4xfOx6r5WlwlaRF2v9qZ2IgecRcm9iUpJXFq+MnWfx9LkM06gn1suRMhl8L h3lIYNcWc3GR04zkpeQBOC5EKvKufeW7cjY9gylVXENEquRKHu1GUk99j5rYHbVYINgU NBO8J366t4on3SR7A0cD6oHJ1RZb2yo9g88NJ/qR6On4+XSkikaAiTOljz3wIlWrE5xh D2JcRpnSSCyyNNaBTSwzurDZ5YtjVHLRAWr42rXsiE9zgBA2OS+2PL0p52sxWhnaiedW 9evg== X-Received: by 10.60.135.1 with SMTP id po1mr19907530oeb.116.1367021733058; Fri, 26 Apr 2013 17:15:33 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id it9sm10045410obb.6.2013.04.26.17.15.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 17:15:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <20130426231430.75437.qmail@joyce.lan> Date: Fri, 26 Apr 2013 17:15:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D821AF2-A61D-438A-A146-82DB97535EAD@gmail.com> References: <20130426231430.75437.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] getting people to use new RRTYPEs 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, 27 Apr 2013 00:15:34 -0000 On Apr 26, 2013, at 4:14 PM, "John Levine" wrote: >> On Thu, Apr 25, 2013 at 06:41:31PM -0700, Doug Barton wrote: >>=20 >>> 1. Insert the ability into the interface to add freeform stuff >>> 2. Run the equivalent of named-checkzone prior to committing the = change >>> 3. Profit! >>=20 >> That's preposterously naive. Step 2.1 is "Find that customer who has >> no theory of the mystifying DNS arcana screwed it up, so you can't >> publish, and now you have to contact a human. Stop. Invoke = expensive >> off-page customer service process." In some significant number of >> cases, we never get to step 3. In the DNS business, the margins are >> small. =20 >=20 > You also forgot step 1.9, in which the software faeries magically > update named-checkzone for every new RRTYPE, even though the times > when new RRTYPEs are defined bear no relation to any sort of software > update or release schedule, and people who want to experiment with new > RRTYPEs are unlikely also to have the skills or inclination to patch > the BIND parser. >=20 > R's, > John >=20 > PS: That's why my hack, using an idea from Vixie, automatically > configures new RRTYPEs as they're published, with no software changes > or updates needed. Again, I don't claim that's the only way to do it, > but I do strongly believe that a useful configurable provisioning or > DNS system can't require per-RR software changes. John, A configurable provisioning scheme sounds nice until you realize a = defined and provisioned method to encode CIDR prefixes in binary existed = several years with suitable input schemes before SPF's text approach was = developed. Bind was not the barrier. It was RPC templates missing in = Windows. Substantial amounts were offered to those willing to implement = Sender-ID, but they themselves were unable to support established DNS = resource records? Do you really think had there been a provisioning = scheme in place things would have been different? =20 If done today, Lists of Address Prefixes (APL RR) sets offer a superior = solution. If APL instead of TXT had been the choice made then, = configuring prefixes would be easier and less burdened with unused = options and poorly considered features. A prefix label in SRV fashion = with APL offers more interesting, concise, and cleaner results. This = may not convince a web designer wanting to add dancing fruit, but XMPP = used web techniques to implement a safer and more scalable StartTLS = solution using binary RRs. Why not do the same with SMTP? =20 Regards, Douglas Otis= From envite@rolamasao.org Fri Apr 26 18:43:51 2013 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 9DDE421F9904 for ; Fri, 26 Apr 2013 18:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogx3jT4bQkY5 for ; Fri, 26 Apr 2013 18:43:51 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6CA21F990E for ; Fri, 26 Apr 2013 18:43:49 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id EEB9B11EAB for ; Sat, 27 Apr 2013 02:43:46 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Sat, 27 Apr 2013 02:43:40 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <20130425013317.36729.qmail@joyce.lan> <517AD619.3000406@dougbarton.us> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1659035.xipCcTsHvt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201304270243.41886.envite@rolamasao.org> Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 27 Apr 2013 01:43:51 -0000 --nextPart1659035.xipCcTsHvt Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Viernes, 26 de abril de 2013 22:58:59 Murray S. Kucherawy wrote: > On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton wrote: > > No, what I'm saying is that the way things were ten years ago > >=20 > > As I (and others) have said many times, things were rough at the time S= PF > > came to bloom. However, and this is really important to understand, it's > > not 10 years ago anymore. >=20 > I am keenly aware of the date. What I am also keenly aware of, as I (and > others) have said many times, is that SPF set off in a specific direction > based on the situation ten years ago and has continued in that direction > all this time. Now, with the situation "at home" > largely-but-not-completely improved, there are a few people now exclaiming > that it went in the wrong direction, and that needs to be fixed. >=20 > It's very easy to make that assertion when one ignores questions of > momentum and inertia. >=20 I'm physicist, so I understand momentum and inertia quite well. I thus can= =20 assure you that even the minimal force can stop and revert even the fastest= =20 movement of the heaviest celestial body. It's just a matter of how much tim= e=20 you apply that force. Here, the momentum and inertia are the deployed base of TXT spf records. Mo= st=20 of them being v1, but the small force of spf 2 changed that movement and th= e=20 body curved the trajectory from "use TXT v1" to "use TXT v1 and 2". Now, if= we=20 recommend SPF over TXT for spf (that's the minimal force) and give enought= =20 time, we'll see how TXT loses positions from almost unique to dominant, the= n=20 to majority, then to coexistent, then to minority, then to historic, then t= o=20 almost unused. It is just a matter of time, and if we start today better th= an=20 tomorrow, well gain the same 1 day at the end of the process. Physics is so simple! Of course, greater forces like deprecating TXT too early can broke things, = in=20 the same way you can receive an egg with your hands (small force) but you'l= l=20 break it if your receive it with a hockey stick. So I suggest we do the right thing, which is not deprecating TXT, but exert= ing=20 the small force: recommending SPF over TXT, and increasing slowly the force= of=20 the recommendation through SPF 3, 4 and so on. Of course, it may be that we'll never reach SPF 4, but it can also be that = an=20 asteroid impacts us before IPv6 gets deployed completely, and we work towar= ds=20 that as well. >=20 > I'm not being petty when I say that. It really is important to understand, >=20 > > the time is going to pass anyway. In the time period between then and n= ow > > a LOT of things have happened in the DNS world, and the situation is > > dramatically different now than it was. Better if is is not dramatical ;) >=20 > Nobody's arguing that point. >=20 > > What is even more important to understand is that 10 years from now 10 > > more years will have passed. We have a chance now to set in motion even= ts > > that will continue to improve the situation, so that 10 years from now = we > > can look back and laugh at the SPF TXT record, and have joy that things > > are so much better. Or, we can spend 10 more years with the same silly > > kludge, and not have made any progress at all. Either way, the next 10 > > years are going to pass. >=20 > Sure. Is that a good use of engineering resources? This is where we > appear to differ. I claim, given current data, that it is not. Reality is addict to do bad use of resources. The amount of engineering use= d=20 to clone Minix just to make it free was (with then-current data) a complete= =20 waste, but The Universe (whatever that means) converted that waste of=20 engineering resources into modern linux. >=20 > > And some of the software that handles SPF has already switched to > > querying SPF/99 first. There is no reason that the rest could not do > > that as well. >=20 > I agree with the first sentence, but not the second. >=20 > > As I have mentioned previously, in the DNS world we have a LOT of > > experience dealing with issues EXACTLY like this. We know how it works, > > we know what long tails look like, and we know that as problems go it's > > a pretty easy problem to deal with. >=20 > This situation touches more than just DNS code. You appear to be convinc= ed > that the path to overcoming inertia in the DNS world is the same, or maybe > even harder, than it is in other environments like email. I am not a > believer. I do not believe, I know. There is nothing that can not be moved. Moreover,= =20 there is nothing that can not be moved with the minimal force over its curr= ent=20 friction limit. We just need to pass that limit. The friction, in this case= ,=20 is those Windows and Providers unwilling to change. As the novel Momo teach= es,=20 they should be moved the last, once the remainder of the "society" is worki= ng=20 the way you want. Do not try to "speak with Momo" too early. >=20 > > Um, it's not "suddenly." The advice to do it right in the first place h= as > > been offered repeatedly, since the very beginning. That's why the code > > point was assigned in the first place. >=20 > Um, it is "suddenly", or have you a copy of the spfbis archive that's > different from the one I have? >=20 > > There is no doubt that in the early days, prior to the widespread > > deployment of 3597, querying for SPF/99 could cause problems. But we're > > not in that world anymore. Thank DNSSEC and IPv6 for shaking things > > loose. There is currently no TECHNICAL reason that the change cannot be > > made NOW to query SPF/99 first. The only argument you (and others) have > > put forward so far is, "We have been using TXT, it works, so we want to > > keep using it." I understand why that course of action is attractive, > > but it's bad. And the right thing isn't hard to do. >=20 > I'm sorry, but that is not the only argument I (and others) have put > forward so far. If this conversation is going to be selective in that > manner, then I think I'm done here. >=20 > -MSK Regards Noel Torres er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart1659035.xipCcTsHvt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlF7LU0ACgkQcLQA8+7Hw3LgdwCfWnagfzdAm3zkmcHa794DQH5/ 9xgAn0OV+ZUuTgdiORpVivXXyAfFDTV1 =Qim5 -----END PGP SIGNATURE----- --nextPart1659035.xipCcTsHvt-- From johnsonhammond2@hushmail.com Sat Apr 27 10:07:35 2013 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 6291721F983B for ; Sat, 27 Apr 2013 10:07:35 -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 ubhQivEnskWZ for ; Sat, 27 Apr 2013 10:07:35 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6921F9837 for ; Sat, 27 Apr 2013 10:07:35 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id DE61A304B2 for ; Sat, 27 Apr 2013 17:06:07 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:06:07 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A274C14DBDE; Sat, 27 Apr 2013 17:06:07 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:06:07 -0400 To: dnsext@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170607.A274C14DBDE@smtp.hushmail.com> Subject: [dnsext] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:10:30 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From ietf@rozanak.com Sat Apr 27 11:50:51 2013 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 8838921F98E6 for ; Sat, 27 Apr 2013 11:50:51 -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 B1j2qvBDfzY2 for ; Sat, 27 Apr 2013 11:50:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6821F98DB for ; Sat, 27 Apr 2013 11:50:49 -0700 (PDT) Received: from kopoli (g225189153.adsl.alicedsl.de [92.225.189.153]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mhhff-1UB2ag1PSl-00MpB1; Sat, 27 Apr 2013 14:50:45 -0400 From: "Hosnieh Rafiee" To: References: <20130427170607.A274C14DBDE@smtp.hushmail.com> In-Reply-To: <20130427170607.A274C14DBDE@smtp.hushmail.com> Date: Sat, 27 Apr 2013 20:50:32 +0200 Message-ID: <000101ce4378$1ebe7d60$5c3b7820$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt0xTMPHyI7UBcdPhIt7U+O5SofZmrRwjw Content-Language: en-us X-Provags-ID: V02:K0:T9ll0MWwZ4w9sjH7WwO1rwp6cZ2Mbg6Ky8T365Bh0Ud 1H6T2Vx1oXF6GLFyb7ssba8RNRa3U8oFP89+4Xw9iNbU4AwOqV WQMKZhARka/5ZOjgzG8CfdEN94ucSjuww/YrjbzC8p6PiidNPk TiNV+dTjbkJk9spO3zUlgqcn5sxZV0Bu61DrrgfVDU+/JzdVjg Sz/a0G41Dmw7iqwwHW33/x3dcXbsCfzKPlROZwK0g9gSBl2YA8 D0fm1ohUBr9qW0rkBNHYj0lT+nQIv48BpRAe3IZwUwCEhkAO3e KhToJdAEHeGU9duc1ku66R4G1j1ADQTf2YjmRSkDQQ3IA/YbrO 2QWDpgxCz5dYQ0iNZNok= Cc: dnsext@ietf.org Subject: Re: [dnsext] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:50:51 -0000 Please do not scam this list and other lists with fake emails. FYI: IETF = is a place to discuss network protocols and standards and not a place to = decide about people.=20 I have never seen the scammer try to ruin the reputation of others with = fake information. If somebody would check the links of Tier they will = understand that there is no relationship between this conference and = what was written. http://www.world-academy-of-science.org/worldcomp13/ws -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of johnsonhammond2@hushmail.com Sent: Saturday, April 27, 2013 7:06 PM To: dnsext@ietf.org Subject: [dnsext] Biggest Fake Conference in Computer Science Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a = study on the world=E2=80=99s biggest bogus computer science conference = WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. = Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper = with a modified title) to WORLDCOMP 2012. This paper had numerous = fundamental mistakes. Sample statements from that paper include:=20 (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed = fuzzy logic (3). Object oriented languages do not exhibit any = polymorphism or inheritance (4). TCP and IP are synonyms and are part of = OSI model (5). Distributed systems deal with only one computer (6). = Laptop is an example for a super computer (7). Operating system is an = example for computer hardware Also, our paper did not express any conceptual meaning. However, it=20 was accepted both the times without any modifications (and without=20 any reviews) and we were invited to submit the final paper and a=20 payment of $500+ fee to present the paper. We decided to use the=20 fee for better purposes than making Prof. Hamid Arabnia (Chairman=20 of WORLDCOMP) rich. After that, we received few reminders from=20 WORLDCOMP to pay the fee but we never responded.=20 We MUST say that you should look at the above website if you have any = thoughts=20 to submit a paper to WORLDCOMP. DBLP and other indexing agencies have = stopped=20 indexing WORLDCOMP=E2=80=99s proceedings since 2011 due to its fakeness. = See=20 http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of = one of the=20 conferences of WORLDCOMP and notice that there is no listing after 2010. = See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known = researchers=20 about WORLDCOMP.=20 The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a = paper than=20 having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business,=20 using University of Georgia mask, for Prof. Hamid Arabnia. He is = throwing=20 out a small chunk of that money (around 20 dollars per paper published=20 in WORLDCOMP=E2=80=99s proceedings) to his puppet (Mr. Ashu Solo or = A.M.G. Solo)=20 who publicizes WORLDCOMP and also defends it at various forums, using=20 fake/anonymous names. The puppet uses fake names and defames other = conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and = tries to=20 threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above = website).=20 That is, the puppet does all his best to get a maximum number of papers = published=20 at WORLDCOMP to get more money into his (and Prof. Hamid = Arabnia=E2=80=99s) pockets.=20 Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until = 2012) has=20 refused to provide the venue for WORLDCOMP=E2=80=9913 because of the = fears of their image=20 being tarnished due to WORLDCOMP=E2=80=99s fraudulent activities. That = is why WORLDCOMP=E2=80=9913=20 is taking place at a different resort. WORLDCOMP will not be held after = 2013.=20 The draft paper submission deadline is over but still there are no = committee=20 members, no reviewers, and there is no conference Chairman. The only = contact=20 details available on WORLDCOMP=E2=80=99s website is just an email = address!=20 Let us make a direct request to Prof. Hamid arabnia: publish all reviews = for=20 all the papers (after blocking identifiable details) since 2000 = conference. Reveal=20 the names and affiliations of all the reviewers (for each year) and how = many=20 papers each reviewer had reviewed on average. We also request him to = look at=20 the Open Challenge (Section 6) at = https://sites.google.com/site/moneycomp1=20 Sorry for posting to multiple lists. Spreading the word is the only way = to stop=20 this bogus conference. Please forward this message to other mailing = lists and people.=20 We are shocked with Prof. Hamid Arabnia and his puppet=E2=80=99s = activities=20 http://worldcomp-fake-bogus.blogspot.com Search Google using the=20 keyword worldcomp fake for additional links. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dhc@dcrocker.net Fri Apr 26 13:24:56 2013 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 EA68521F9846; Fri, 26 Apr 2013 13:24:56 -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 Xs7xFgtv0DO6; Fri, 26 Apr 2013 13:24:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD621F982C; Fri, 26 Apr 2013 13:24:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3QKOq5s013108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 13:24:56 -0700 Message-ID: <517AE290.6030303@dcrocker.net> Date: Fri, 26 Apr 2013 13:24:48 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 26 Apr 2013 13:24:56 -0700 (PDT) X-Mailman-Approved-At: Sat, 27 Apr 2013 12:27:17 -0700 Cc: spfbis@ietf.org Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:24:57 -0000 On 4/23/2013 3:03 PM, S Moonesamy wrote: > Hello, > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > Is the annotation in the DNS Parameters registry correct? Dear DNSEXT, For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked. DNSEXT was asked to provide expert review of this specific bit of text. The text is intended to be comparable to the way that some other, similar situations have already been handled. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Thu Apr 25 10:54:14 2013 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 D21CB21F967F for ; Thu, 25 Apr 2013 10:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 bq23oDmoPb4y for ; Thu, 25 Apr 2013 10:54:06 -0700 (PDT) Received: from catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D4D3421F9696 for ; Thu, 25 Apr 2013 10:53:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2725; t=1366912434; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=SqtMBAI QPUpTueyoK+8s5pX2MZA=; b=oNfbvPJq74kxuuyG2nSvd4QpM+tMuU2yI48jSNo rU5rvxsY/xnypjP+qR4gF0kD6KRDVBeJAlrA1ifIfKwdEDVug4/Ij2m0IDgZt4GN IUDCm7PyuAmW6Notwz7YQ1CTVrnVZ8/6rgnLnhQ63h6SNRp1yXwUtYEUa9fbRk6R XdrA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Thu, 25 Apr 2013 13:53:54 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1411156575.615.4836; Thu, 25 Apr 2013 13:53:54 -0400 Message-ID: <51796D62.2090609@isdg.net> Date: Thu, 25 Apr 2013 13:52:34 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> In-Reply-To: <5179691B.50602@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 27 Apr 2013 12:27:53 -0700 Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:54:14 -0000 In my view, since I was the one who posted and asked questions about this very issue in IETF and DNSOP to get a feel about the unnamed RRTYPE and rfc3597 "Handling of Unknown DNS Resource Record (RR) Types", the current status quo, nine years later, what most preferred, I don't believe there was a consensus when you include the inputs from the other list to just stay with TXT. My concern was whether an RFC will be "sanctioned" as a proposed standard for what most experts believe, including myself, is a KLUDGE solution and not ideal in large scale and worst as more and more protocols are written using a TXT only solutions, its all limited. What I felt is that some were some key folks who were now more accepting of a TXT based record and possibly because DNS servers have failed to keep up with this need (support RFC3597 or something like it). That was the expectation in my view and we expected a long term migration to occur too. I would support keeping the RRTYPE. I believe it is be less of a cost issue - implementators don't have to "UPGRADE/KEEP UP" to BIS by removing RRTYPE overhead. By making it obsolete, you automatically make all SPF implementators "out of date." Anyway, I am not too sure if everyone will like this outside the SPF BIS group. I didn't get that feel. Only a selective few (key cogs) that are part of this work has began to show an acceptance to it. So if that matters, what is what I was trying to feel in IETF and DNSOP - who else agreed with that from an endorsement standpoint. -- HLS On 4/25/2013 1:34 PM, Pete Resnick wrote: > On 4/25/13 10:42 AM, Måns Nilsson wrote: >> And IMNSHO spfbis is out of scope prescribing TXT records, just because >> of this contagiousness. >> >> For the record: I think that the spfbis draft is unfit for publication >> as RFC unless TXT records are deprectaed as only carrier of data. > > SPFBIS AD hat on for this: > > We are *long* past this discussion. This discussion should have happened > at SPFBIS *chartering* time, as it is crystal clear from the charter > that existing features currently in use in SPF are not going away. > Indeed, the TXT record was specifically mentioned in the charter. > > I certainly have the same heartburn as everyone else about having used > TXT in this manner, but that ship has long sailed. This is running and > interoperable code and it is being documented on the standards track. > Unless you think there is a piece of information I missed in my > assessment that we had consensus to go forward with this work in the > first place, you are going to have a hard time convincing me that this > is not in the rough part of the consensus now. > > pr > From spf2@kitterman.com Fri Apr 26 08:09:29 2013 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 70DFC21F97F7; Fri, 26 Apr 2013 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 GCYQd4M9wU8A; Fri, 26 Apr 2013 08:09:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E102C21F974E; Fri, 26 Apr 2013 08:09:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2C97C20E40D5; Fri, 26 Apr 2013 11:09:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366988968; bh=V7gYHjwxQx5871aR/yjpbS0s3EHEo+Rial4rbIICB2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a9ff8vNpZ1Y5Fx/woHK6UmcWRWAIS9vy9yt9pxNKpBOp1IyBNA1ylRELp6BDc9Nr3 XMwUNnVJUdmYyoFaHyC29gZzQuCdNHjk6J5H1HwPz3ziuPxWpp7TXWnkSPoxNm2KEQ q/UpXTYQhGXCHMBhHC/a6+Zh7C6Fl4TsNFQqVg40= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 10A0520E40CF; Fri, 26 Apr 2013 11:09:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, "dnsext@ietf.org" Date: Fri, 26 Apr 2013 11:09:17 -0400 Message-ID: <4261639.Sk6X1reqIa@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 27 Apr 2013 12:29:59 -0700 Cc: Ted Lemon Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:09:29 -0000 On Friday, April 26, 2013 07:52:29 AM Murray S. Kucherawy wrote: > > 2. Because TXT records aren't specific to SPF, a query for TXT records may > > return an unexpectedly large result set, requiring fallback to TCP. > > Rejoinder: doesn't seem to be an issue in practice. > > That's not correct; there are still packet filters out there configured by > default to disallow TCP over port 53. We discovered this during the > RFC6686 surveys. And, in the event a domain needs enough other TXT data that an SPF record would cause it to spill over into TCP, it's trivially solvable. For example.com: example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" It needn't ever be more impact than that. Scott K From spf2@kitterman.com Fri Apr 26 14:58:10 2013 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 6CD4C21F99EC; Fri, 26 Apr 2013 14:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 wViT2BaFemHf; Fri, 26 Apr 2013 14:58:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3ACB21F998B; Fri, 26 Apr 2013 14:58:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1EE7020E40D5; Fri, 26 Apr 2013 17:58:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367013483; bh=m4YeNCTTcSVPJvj6xkSF4d6s8k9p3hL41j4DrhCte1Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z7ssnVkGjOwdBgIj/ceT2PVp2wGtjO6fatn74r6eS7DWizBJUs0eSfykZT/S1N62t L3xLkXnc2uePBXj4c63Wk4B4sQ4tM/62pTdx/yzDWoPjB89K7KUvfmfiJTzTonkWLK WrPpls+TOajFTF56mkgXwIjdRiad6LyzJ3HWCsLU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 03A0220E40CF; Fri, 26 Apr 2013 17:58:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, dnsext@ietf.org Date: Fri, 26 Apr 2013 17:58:02 -0400 Message-ID: <11684211.aVagNjs4Ck@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 27 Apr 2013 12:30:25 -0700 Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:58:10 -0000 Thanks. Having looked at that, I think that the text in the original question from sm is OK (modulo we don't redesign things - please keep that in a different subthread). Scott K On Friday, April 26, 2013 03:55:01 PM David Conrad wrote: > Dave, > > As I pointed out to Paul Hoffman, the message I sent that I believe started > this thread said: > > "It is in keeping with past practice, e.g., see the notations for MD, MF, > A6, and the MAILA RRtypes at > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml." > > Regards, > -drc > > On Apr 26, 2013, at 3:43 PM, Dave Crocker wrote: > > On 4/23/2013 3:03 PM, S Moonesamy wrote: > >> Hello, > >> > >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > >> 'IANA is requested to add an annotation to the SPF RRTYPE saying > >> > >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > >> > >> Is the annotation in the DNS Parameters registry correct? > > > > Dear DNSEXT, > > > > For all of the really interesting side discussions that have developed > > since SM sent this initial query, I believe there have not been any > > responses that answered the question that was asked. > > > > DNSEXT was asked to provide expert review of this specific bit of text. > > The text is intended to be comparable to the way that some other, similar > > situations have already been handled. > > > > d/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Sun Apr 28 06:50:00 2013 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 1927921F983D for ; Sun, 28 Apr 2013 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.411, 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 DoMbGemgHaFc for ; Sun, 28 Apr 2013 06:49:59 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F215221F9821 for ; Sun, 28 Apr 2013 06:49:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2098; t=1367156996; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=x24nGze f8W0KwMewy+T8Px6Gdko=; b=Dd2RJHAFSL+xoyeH2VOAgFMqhfTEjV6SnqGIXq9 QK6AB1TXpJ4G5I0YJorNuFoE/3hHQhDRuGrSGAqMHQ2cPDrEQYEBbEgckNLJZCWa xRP2vcBS+7YWo+z8s1WKZUU7YyrOE3LpUG4FLMA4TB/MeSaBo3aIppSh7gjUVs/t uqrA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sun, 28 Apr 2013 09:49:56 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1655715817.4028.5192; Sun, 28 Apr 2013 09:49:56 -0400 Message-ID: <517D28B1.1050401@isdg.net> Date: Sun, 28 Apr 2013 09:48:33 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org, "dnsext@ietf.org Group" References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> In-Reply-To: <517D1F06.2080109@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE 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, 28 Apr 2013 13:50:00 -0000 I would like to suggest before eliminating (deprecating) SPF RRTYPE, in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or whoever manages/codes the main infrastructure DNS servers) why they are not supporting unnamed type processing? Are they even aware of this need? I believe BIND supports it, but not Microsoft DNS server. How about others? Are they all/mostly based on Bind source code? I tried to find out last March 2012 in the Microsoft Windows Server Tech Forum [1] if Microsoft DNS v5.0 supported RFC3597 [2] or unnamed type processing, and it wasn't known or I just didn't reach the right folks. It was surprising that not even Ace Fakey was not aware of this need. -- HLS [1] http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/5841e884-db22-42a1-8530-615a375662cc/ [2] http://tools.ietf.org/html/rfc3597 On 4/28/2013 9:07 AM, Hector Santos wrote: > But this isn't a complex problem. It is a simple solution. The goal is > for the docs to described what DEVELOPERS need to do, or should do, to > prepare for the "Future." > > o Select method of SPF lookups > (_) SPF RRTYPE only > (*) TXT RRTYPE only > (_) BOTH (SPF/TXT) > > Protocol Options are always part of the design game. > > The only real problem, is that we currently do not have any control over > this future (DNS Servers supporting unnamed type processing). There is > seriously a lack of communications going on. Where are these DNS > vendors? Who are the key folks who have some "control" over this future? > > > On 4/28/2013 8:18 AM, Andrew Sullivan wrote: >> No hat. >> >> On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote: >> >>> I will be implementing this myself in the next week or so. Should >>> be very simple. >> >> I believe it was Mencken who said, "For every complex problem there is >> an answer that is clear, simple, and wrong." >> >> Best, >> >> A >> > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From drc@virtualized.org Sun Apr 28 16:58:05 2013 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 0EC1E21F9887 for ; Sun, 28 Apr 2013 16:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 FJiAzMWLeKUJ for ; Sun, 28 Apr 2013 16:58:04 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 497F821F9868 for ; Sun, 28 Apr 2013 16:58:01 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-137-149-147.mycingular.net [166.137.149.147]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 66D3A17166; Sun, 28 Apr 2013 23:57:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <20130426214956.75110.qmail@joyce.lan> Date: Sun, 28 Apr 2013 18:57:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> References: <20130426214956.75110.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 23:58:05 -0000 [Apologies for delays, travel distractions] John, On Apr 26, 2013, at 4:49 PM, John Levine wrote: >> Well, deprecating the SPF RR will certainly teach the = DNSEXT/IESG/IETF community a good lesson. (Seriously?) > This may come as a surprise, but this isn't all about you. =20 Damn. Burst my bubble. But I'd note that this isn't all about you or = the other participants of SPFBIS either. It's actually about the future. > For all its warts, SPF works fine > as is, and they have no incentive to change. Hence the narrow charter > of the group only to clean up the existing spec, not to extend or > change it. Err, SPFBIS _does_ change the spec. It is proposing to deprecate the RR = specifically created for SPF and state that compliant implementations = only use TXT. >> And how do you propose that exactly, particularly given the precedent = set by SPFBIS? > Provide the tools and processes so that people can use new RRTYPEs in > new designs. (Insert usual point about provisioning.) While I know you'd like to use this to drive dnsextlang (something I = support), given the SPF RR semantics are identical to TXT RRs and the = complexity associated with implementing (minimal) support for SPF is = changing code to emit "99" instead of "16", I have a bit of skepticism = that better tools/processes are actually the driving force here. > Don't shoot yourself in the foot by demanding that we break one that's > a decade old and likely in wider use than 95% of all of the other IETF > protocols. Strawman. Can you point to any message "demanding that we break" = _anything_? Similarly, can you point to anyone who claims using TXT is = the best choice as opposed to the pragmatic choice? What I believe = people (including myself) are saying is that the abandonment of a = migration away from TXT is simply the wrong way to go and that a better = approach would be to continue to encourage migration to SPF (with = backwards compatibility, of course), even if it will take time.=20 In any event, DNSEXT is the wrong venue to discuss the SPFBIS strategy. = I suppose the right course of action is to write up a draft entitled = "TXT Considered Harmful" or somesuch. Regards, -drc From johnl@taugh.com Sun Apr 28 17:34:02 2013 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 E1B7321F980B for ; Sun, 28 Apr 2013 17:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 M288GCYBQgpx for ; Sun, 28 Apr 2013 17:34:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E72E821F9804 for ; Sun, 28 Apr 2013 17:34:01 -0700 (PDT) Received: (qmail 45978 invoked from network); 29 Apr 2013 00:34:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b399.517dbff9.k1304; bh=wwn5m4hpNGbsXxwh1plcGOqCwsrNtXWRe5sE7wYmDEU=; b=jmN2sYuv5bOOB+vKTDDYd+hqXw4jInzTu5+gg3DBi3Q6E8oWSZ0Sj5hcHyuKEV3+41foAsEHzt5ij4NyJrS9nY2FB6JVQW9tpsrKoUvHRhpHZofdM5x0FHp5ninOXty8I5KvAb/RjGJuBx75OB84parwPbniT16QxrWzF9s+qvk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b399.517dbff9.k1304; bh=wwn5m4hpNGbsXxwh1plcGOqCwsrNtXWRe5sE7wYmDEU=; b=1i51fpbbjtQ8wzCF1rBIe1La8yGaugJGgYjaT0HOIqDx7tJ54wbtxDI8y1xC6jTzLYT1OMAncA75eYZmvHfnXkHdrEjyY3cr4v/zoK41+Mf5PaVjl6tsz0ie/pF0tBhDhzH36Q8YMCiO9XOfzo+JJYC3PxzSpkps1CGn/0IqQJE= Received: (ofmipd 127.0.0.1); 29 Apr 2013 00:33:38 -0000 Date: 28 Apr 2013 20:34:00 -0400 Message-ID: From: "John R Levine" To: "David Conrad" In-Reply-To: <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> References: <20130426214956.75110.qmail@joyce.lan> <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 00:34:03 -0000 >> Don't shoot yourself in the foot by demanding that we break one that's >> a decade old and likely in wider use than 95% of all of the other IETF >> protocols. > > Strawman. Can you point to any message "demanding that we break" _anything_? Yes. Read the spfbis list archives for details. > Similarly, can you point to anyone who claims using TXT is >the best choice as opposed to the pragmatic choice? No. But engineers make pragmatic choices. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dougb@dougbarton.us Sun Apr 28 17:52:17 2013 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 7BF2721F9777 for ; Sun, 28 Apr 2013 17:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 SyAB926sPtUA for ; Sun, 28 Apr 2013 17:52:16 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC521F9603 for ; Sun, 28 Apr 2013 17:52:16 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c] (unknown [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c]) by dougbarton.us (Postfix) with ESMTPSA id B079122B62 for ; Mon, 29 Apr 2013 00:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367196736; bh=1lp8s/CUcxfcdY3jLh8bAQ8V21t/4q7np8DhdMniqkk=; h=Date:From:To:Subject:References:In-Reply-To; b=f+EpIsJ9eGE8kBy1MfytzXkapGDHQ2N/yKj5mwsuxLGP4Ff1mWrLg6UkUYLHudYkB MdMAZ8PmYMqDkzZ33qyhi+FVjNZqm/rBx/TyThrrp1GJsZsXrG3UOk7lED2QdkheuS DMmVaqbUfpiZRtzu0c6OfSVuZQTa+rG38tS7ly8Y= Message-ID: <517DC440.1040208@dougbarton.us> Date: Sun, 28 Apr 2013 17:52:16 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130426214956.75110.qmail@joyce.lan> <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 00:52:17 -0000 On 04/28/2013 05:34 PM, John R Levine wrote: >>> Don't shoot yourself in the foot by demanding that we break one that's >>> a decade old and likely in wider use than 95% of all of the other IETF >>> protocols. >> >> Strawman. Can you point to any message "demanding that we break" >> _anything_? > > Yes. Read the spfbis list archives for details. I did, and didn't find anything that said that changing to querying SPF first would break anything _now_. If you're going to make the argument that it does, be explicit. The fact that at various times in the past, especially pre-3597, there were problems doesn't factor in. >> Similarly, can you point to anyone who claims using TXT is the best >> choice as opposed to the pragmatic choice? > > No. But engineers make pragmatic choices. And in this case doing the right thing is easy, so absent any concrete reasons not to ... Doug From johnl@iecc.com Sun Apr 28 18:32:29 2013 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 3AC9221F9699 for ; Sun, 28 Apr 2013 18:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.3 X-Spam-Level: X-Spam-Status: No, score=-104.3 tagged_above=-999 required=5 tests=[AWL=4.300, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 Bs31xy0G6fAz for ; Sun, 28 Apr 2013 18:32:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 61EE021F969F for ; Sun, 28 Apr 2013 18:32:28 -0700 (PDT) Received: (qmail 55126 invoked from network); 29 Apr 2013 01:32:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Apr 2013 01:32:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517dcdab.xn--hew.k1304; i=johnl@user.iecc.com; bh=C8aFA4QJIQDGgSrrsKVlGrpccYkk+h4qbq0J++hGtD8=; b=JOml5RYb7oZAveW+lYaI2n+8GIRFyO2uAkhtBjMmZH0W6h3zgfUEBFkYb7uizOmeyZuF7W3oYv1xqYXUHbH7VmE8w+lJINPCPVIv3xvBdfCoCDopg1Ac/YnO7/OuQsoys5/0S2yiWYs0D6Bh9Ec8iMCYitFQlj6SGHE1pgMzcXc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=517dcdab.xn--hew.k1304; olt=johnl@user.iecc.com; bh=C8aFA4QJIQDGgSrrsKVlGrpccYkk+h4qbq0J++hGtD8=; b=tuTVVMujJyy/CYuhD+/wLXcE3PjKNS+YhCaxTGzTPqFYaxip4v9tduSQHMYhG667frADqw/+CPIQR2tFxwg2NOmddwXvSOIvUb/aL5icSbaRGDXGfDGmndd8k4s1w8Z1gFmlwUNDIbF0t3niobUBvz2Gl88SD6D7QuI70fH2oGs= Date: 29 Apr 2013 01:32:05 -0000 Message-ID: <20130429013205.98968.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <517DC440.1040208@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 01:32:29 -0000 >>> Strawman. Can you point to any message "demanding that we break" >>> _anything_? >> >> Yes. Read the spfbis list archives for details. > >I did, and didn't find anything that said that changing to querying SPF >first would break anything _now_. It's there, read it again. R's, John From dougb@dougbarton.us Sun Apr 28 18:34:15 2013 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 5471921F9708 for ; Sun, 28 Apr 2013 18:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 vUffT-yVg7xB for ; Sun, 28 Apr 2013 18:34:14 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC821F9699 for ; Sun, 28 Apr 2013 18:34:14 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c] (unknown [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c]) by dougbarton.us (Postfix) with ESMTPSA id 6F5DF22B62 for ; Mon, 29 Apr 2013 01:34:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367199254; bh=7Bu/dzrJcKY2j67awgBAanfzQSioTtpYqA9whV1w56Y=; h=Date:From:To:Subject:References:In-Reply-To; b=boI0ihMkySzziqyHDj1C5jduGoB0YGBhVeNcsS5PQHiL6W9XkMknoMwIuwZHvwEtt HAO4qMePVjw0ro3Yx12ejDpxWSrSFhk187peNbvYAV8JXr4vnGOPPDxHChuCR7oqBg 9KeDfOLWYf2gMZ6tjR/hAeXHEC3APhX6Gy3j6LNc= Message-ID: <517DCE16.3090906@dougbarton.us> Date: Sun, 28 Apr 2013 18:34:14 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130429013205.98968.qmail@joyce.lan> In-Reply-To: <20130429013205.98968.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 01:34:15 -0000 On 04/28/2013 06:32 PM, John Levine wrote: >>>> Strawman. Can you point to any message "demanding that we break" >>>> _anything_? >>> >>> Yes. Read the spfbis list archives for details. >> >> I did, and didn't find anything that said that changing to querying SPF >> first would break anything _now_. > > It's there, read it again. Sorry, I've spent way too much time on this already, and I've given a thorough analysis of what I did and didn't find in the archives. If you have an argument to make, make it. If not, admit that you're just not willing to do the work necessary to make the change. Doug From he@uninett.no Mon Apr 29 04:47:04 2013 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 9869921F9D3E for ; Mon, 29 Apr 2013 04:47: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 jgJ3IfdeuGbh for ; Mon, 29 Apr 2013 04:47:04 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3921F97D1 for ; Mon, 29 Apr 2013 04:47:00 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 8E6E53D0B3; Mon, 29 Apr 2013 13:46:58 +0200 (CEST) Date: Mon, 29 Apr 2013 13:46:58 +0200 (CEST) Message-Id: <20130429.134658.05901860.he@uninett.no> To: drc@virtualized.org From: Havard Eidnes In-Reply-To: <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> References: <20130426214956.75110.qmail@joyce.lan> <3316FDF5-F97A-4D17-8B47-AF5B86C741DA@virtualized.org> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 11:47:04 -0000 > [...] I suppose the right course of action is to write up a > draft entitled "TXT Considered Harmful" or somesuch. Isn't that what RFC 5507 is all about? Quoting from the conclusion part: Given the various issues described in this note, we believe that: o there is no magic solution that allows a completely painless addition of new data to the DNS, but o on the whole, the best solution is still to use the DNS Resource Record Type mechanism designed for precisely this purpose, whenever possible, and o of all the alternate solutions, the "obvious" approach of using TXT Resource Records for arbitrary names is almost certainly the worst, especially for the two reasons outlined above (lack of semantics and its implementations, and size leading to the need t= o use TCP). which seems pretty clear-cut to me. Regards, - H=E5vard From ed.lewis@neustar.biz Mon Apr 29 07:49:33 2013 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 D29C921F9E4C for ; Mon, 29 Apr 2013 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.713 X-Spam-Level: X-Spam-Status: No, score=-100.713 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 h7jO-ZXqzWFu for ; Mon, 29 Apr 2013 07:49:33 -0700 (PDT) Received: from smtp155.ord.emailsrvr.com (smtp155.ord.emailsrvr.com [173.203.6.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4121F9E40 for ; Mon, 29 Apr 2013 07:49:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id D328B1C0192; Mon, 29 Apr 2013 10:49:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 8D1991C00FC; Mon, 29 Apr 2013 10:49:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DF8C6926-DA65-41E7-8A0E-1875332D7BDA" From: Edward Lewis In-Reply-To: <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> Date: Mon, 29 Apr 2013 10:49:32 -0400 Message-Id: <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> To: "dnsext@ietf.org Group" X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 14:49:33 -0000 --Apple-Mail=_DF8C6926-DA65-41E7-8A0E-1875332D7BDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 25, 2013, at 0:37, David Conrad wrote: >=20 > Actually, I'm more intrigued as to the view of the folks on DNSEXT on = this issue. I'm tired of hearing about it. The only concern is that pushing more data into TXT records is that, if = more than one application does this and involves the same name, we are = increasing the number of large RRsets pushed around. Why this is only = tiring and not a really big problem is - we have other large RRsets = already and it takes a name and application collision. One application = using TXT instead of BLAH makes no difference. The number of bytes is = the same. Only when BLAH and URGH combine themselves into *a* TXT is = there bloat (for both applications). And bloat is only a problem in the = general sense when reflection/amplification is an issue. It's not so much a DNS *protocol/architectural" or "operations* issue. = It's more of a matter for applications (to avoid bloat) and for = anti-abuse techniques (to avoid amplification). = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_DF8C6926-DA65-41E7-8A0E-1875332D7BDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Actually, I'm = more intrigued as to the view of the folks on DNSEXT on this = issue.

I'm tired of hearing about = it.

The only concern is that pushing more data = into TXT records is that, if more than one application does this and = involves the same name, we are increasing the number of large RRsets = pushed around.  Why this is only tiring and not a really big = problem is - we have other large RRsets already and it takes a name and = application collision.  One application using TXT instead of BLAH = makes no difference.  The number of bytes is the same.  Only = when BLAH and URGH combine themselves into *a* TXT is there bloat (for = both applications).  And bloat is only a problem in the general = sense when reflection/amplification is an = issue.

It's not so much a DNS = *protocol/architectural" or "operations* issue.  It's more of a = matter for applications (to avoid bloat) and for anti-abuse techniques = (to avoid amplification).

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_DF8C6926-DA65-41E7-8A0E-1875332D7BDA-- From jim@rfc1035.com Mon Apr 29 08:19:24 2013 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 5D05121F9DF4 for ; Mon, 29 Apr 2013 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qLEyAVC3+BEo for ; Mon, 29 Apr 2013 08:19:23 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC3921F9D98 for ; Mon, 29 Apr 2013 08:19:23 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [IPv6:2001:4b10:100:7::42]) by shaun.rfc1035.com (Postfix) with ESMTP id 1BB46CBC41F; Mon, 29 Apr 2013 16:19:22 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> Date: Mon, 29 Apr 2013 16:19:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: [dnsext] loads of TXT records for fun and profit 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, 29 Apr 2013 15:19:24 -0000 On 29 Apr 2013, at 15:49, Edward Lewis wrote: > The only concern is that pushing more data into TXT records is that, = if more than one application does this and involves the same name, we = are increasing the number of large RRsets pushed around. Nope. ALL the applications looking up TXT records will have to wade = through a pile of them to find and make sense of the one(s) that are of = specific interest. Good luck if > 1 of these TXT records have similar = RDATA but are meant for use by different things. Though perhaps that's = just a concern for dnsop or developers rather than this WG. Frankly, it's beyond stupid to overload TXT records now a unique RRtype = code is simple to get (ha!) or some prefix convention could be applied: = like adding _spf (say) to the QNAME so a big bunch of TXT records don't = all have to sit at the same node in the tree. From drc@virtualized.org Mon Apr 29 20:22:37 2013 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 427E521F9C2F for ; Mon, 29 Apr 2013 20:22:37 -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 au2yf8PnwaYf for ; Mon, 29 Apr 2013 20:22:31 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1A21F9C25 for ; Mon, 29 Apr 2013 20:22:29 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id C6E4217184; Tue, 30 Apr 2013 03:22:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> Date: Mon, 29 Apr 2013 20:22:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 03:22:37 -0000 Ed, On Apr 29, 2013, at 7:49 AM, Edward Lewis wrote: > On Apr 25, 2013, at 0:37, David Conrad wrote: >> Actually, I'm more intrigued as to the view of the folks on DNSEXT on = this issue. > I'm tired of hearing about it. Sorry to hear that. > The only concern is that pushing more data into TXT records is that, = if more than one application does this and involves the same name, we = are increasing the number of large RRsets pushed around. Well, no. That's not the only concern: 1) it moves the mechanism to uniquify a DNS response out of the DNS = library and into the application, forcing every protocol-specific = library or application to have to deal with uniquifying the response in = their own unique (and undoubtedly in some cases fascinating) way; 2) given individual RR order within an RRset is not guaranteed, it = significantly complicates TXT RDATA parsing logic for any application = that cares about TXT RRs; 3) It means you've reduced the amount of usable space in the RDATA since = you have to have some unique string in the RDATA to key off of; and 4) because other protocols may use TXT at the same (unfortunately = common) ownername, it becomes more probable that the size of the = response will go over the 512 limit resulting in fragmentation or = fallback to TCP increases, which imposes potential load and reachability = issues, not just for SPF but for any other protocol that is using TXT at = that ownername > It's not so much a DNS *protocol/architectural" or "operations* issue. = It's more of a matter for applications (to avoid bloat) and for = anti-abuse techniques (to avoid amplification). While I agree that bloat/amplification is an issue, SPFBIS's decision = impacts any future protocol that might use TXT at the same ownername as = SPF. The implication to DNSEXT is obviously that we should discourage = TXT at the same ownernames as SPF uses (if not generally), but I figure = that's already sort of been done. Unfortunately, I suspect "pragmatists" = won't listen to such advice and then you get all of the above fun. That's why I said "I personally believe deprecating the SPF RR is the = wrong way to go". Regards, -drc From paf@frobbit.se Mon Apr 29 21:42:56 2013 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 4BC1021F987E for ; Mon, 29 Apr 2013 21:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1KJy89M3Ms9 for ; Mon, 29 Apr 2013 21:42:55 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C134A21F9AD9 for ; Mon, 29 Apr 2013 21:42:30 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id 9DDB721232; Tue, 30 Apr 2013 06:42:26 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org> Date: Tue, 30 Apr 2013 06:42:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B2DEDE4-1038-4A24-8A7C-213223A64CF9@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1503) Cc: Edward Lewis , "dnsext@ietf.org Group" Subject: Re: [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 04:42:56 -0000 On 30 apr 2013, at 05:22, David Conrad wrote: >> The only concern is that pushing more data into TXT records is that, = if more than one application does this and involves the same name, we = are increasing the number of large RRsets pushed around. >=20 > Well, no. That's not the only concern: >=20 > 1) it moves the mechanism to uniquify a DNS response out of the DNS = library and into the application, forcing every protocol-specific = library or application to have to deal with uniquifying the response in = their own unique (and undoubtedly in some cases fascinating) way; >=20 > 2) given individual RR order within an RRset is not guaranteed, it = significantly complicates TXT RDATA parsing logic for any application = that cares about TXT RRs; >=20 > 3) It means you've reduced the amount of usable space in the RDATA = since you have to have some unique string in the RDATA to key off of; = and >=20 > 4) because other protocols may use TXT at the same (unfortunately = common) ownername, it becomes more probable that the size of the = response will go over the 512 limit resulting in fragmentation or = fallback to TCP increases, which imposes potential load and reachability = issues, not just for SPF but for any other protocol that is using TXT at = that ownername As I have written before: 5) As multiple different usages of RR in DNS use the same owner and = class, separation of the records in the query/response must be done via = prefix on the owner. This implies multiple records can end up on = different sides of a zone cut where a DNSSEC administrative boundary is = located. For example, the MX might be signed, but the TXT for the same = domain, but with a prefix, might be unsigned. The security implications = of such differences in DNSSEC implications (key rollower etc) has not = been investigated. I believe it is a weakness, or rather, it is a = strength that all records that are "similar" can have the same owner and = because of that be in the same zone. It was not a coincidence I took the initiative to write RFC 5507. I am = _really_ concerned over use of TXT the way it is done by the SPF = "solution". Patrik From wwwrun@rfc-editor.org Tue Apr 30 22:33:12 2013 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 BF8A221F8693; Tue, 30 Apr 2013 22:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 rhU39-fEpkUz; Tue, 30 Apr 2013 22:33:12 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D621F84E3; Tue, 30 Apr 2013 22:33:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F3427B1E014; Tue, 30 Apr 2013 22:32:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130501053241.F3427B1E014@rfc-editor.org> Date: Tue, 30 Apr 2013 22:32:41 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6944 on Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation 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, 01 May 2013 05:33:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6944 Title: Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status Author: S. Rose Status: Standards Track Stream: IETF Date: April 2013 Mailbox: scottr.nist@gmail.com Pages: 7 Characters: 13876 Updates: RFC 2536, RFC 2539, RFC 3110, RFC 4034, RFC 4398, RFC 5155, RFC 5702, RFC 5933 I-D Tag: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt URL: http://www.rfc-editor.org/rfc/rfc6944.txt The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC