From nobody Thu May 1 08:24:54 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853ED1A0902 for ; Thu, 1 May 2014 08:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYiN-U3nP4Wd for ; Thu, 1 May 2014 08:24:48 -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 246DB1A08ED for ; Thu, 1 May 2014 08:24:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.144.249]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s41FOYpf011726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 May 2014 08:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398957885; bh=GZTfOyEXJdO0qakdF5mM6f9mq9k50BeNWODMrh5pVz0=; h=Date:To:From:Subject; b=L6x2OZ3mq14WwgMMW3Ud71qAKV0Pl3TaggsmjbSBFxnaWqs+dfGuiLPW2/+7IzpPM rhWc8BYv2kUkUrLhdSK0D4u7uYvyttyFGEBpLwYFwsx2qfAFLEW8Erl9H527Cr/SVJ 2WKue587tpExntyGFnQtzKmR+v+3bF7Iu7oLurcw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398957885; i=@elandsys.com; bh=GZTfOyEXJdO0qakdF5mM6f9mq9k50BeNWODMrh5pVz0=; h=Date:To:From:Subject; b=r3N8XdNTL1VKYSq2F1ACFItFfMDkY0M8XeZR9uh1y9TI8kAoWlLDJIJhfWBLyUe+p emUHUH5GDxkuZBmBed2dlTI8Qvk84EM990BO4PUvR9QAarDN3vilFnwdugjxom6AB/ aUeFE+B2xGdn7Z07QIGpvqO5osxHiZMaAxmPXt2M= Message-Id: <6.2.5.6.2.20140501081606.0c8d81e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 May 2014 08:20:51 -0700 To: dnsext@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/0Je54IVXSSBHPDjy_O5TqrAQKkw Subject: [dnsext] Fwd: Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 15:24:49 -0000 Hello, I am forwarding this Last Call announcement (see below) as it is something to do with DNS. Regards, S. Moonesamy >The IESG has received a request from an individual submitter to consider >the following document: >- 'Using ED25519 in SSHFP Resource Records' > as Informational RFC > >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 2014-05-29. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > The Ed25519 signature algorithm has been implemented in OpenSSH. > This document updates the IANA "SSHFP RR Types for public key > algorithms" registry by adding an algorithm number for Ed25519. > > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > >Note that there is no current standardised format for the input >to the hash function here, but there are two implementations >of this so a codepoint is needed and useful. A standard public >key format is likely to be developed in future (but could take >some time) at which point it may make sense to assign another >codepoint, but there are no issues with codepoint scarcity here >so that seems like it will work given the implemeners seem ok >with it, even if its not ideal. From nobody Thu May 1 09:00:26 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91251A0902 for ; Thu, 1 May 2014 09:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVag6UgWujS1 for ; Thu, 1 May 2014 09:00:21 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 344EE1A08ED for ; Thu, 1 May 2014 09:00:21 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id e16so971759qcx.14 for ; Thu, 01 May 2014 09:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G3+CvqWNzKGT8R9PpJRpfm+kL9Lt3om016blDupvhhA=; b=pa5WGsyoMiOyro1ITV7ClmBY42qr1A/o+9OR5bgfWfPc421cEeHPTAdE4ISkmlupR1 xKPbrYzWJ9CmxAT5aGjg1bToKZWy4+a6ili+PUwzsN6TaNVVS1hKatW1qjZBEGS190DW 3gpM8vOVvATM1j1/zH8bhRDwJ/rzPtDMAiWrM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=G3+CvqWNzKGT8R9PpJRpfm+kL9Lt3om016blDupvhhA=; b=XZslARojn+szywbSlbpqKxfNSUw4pdC/BJdPV9ifzx88FShpOacW9I5YkBVwpTymsL UlZUr2MSIyGyU2pJf1baaAFdM5GAvWg3NST6UwEJJU9F3RBuOTimF2H2Soi/KdlxhZER r0rlKmyzMC0dKushFgxvYihyyojXDBLfRblLD5LJyWxaG/L8sFkR1K9Lb9va5IjcLHvT ALFHW65zgf0trJdikXqCUxPQMAZL2RdVvYrXTuLFgM3rXE+iy+7gda7wUnRp/i8bolaH M+HBplELzVs5Zb+tZjsN77B+ZAO40g43MMV9xHaHlhLsntyDjzG11sYjZjGRNYqB0MqD qw3g== X-Gm-Message-State: ALoCoQmXUPN8RU1FmA7t98aNSlmS/02bmTux3rPxR6DObh4MnBGOXZe/0eYZrualIlvyu//c7Gad X-Received: by 10.224.20.196 with SMTP id g4mr14830665qab.66.1398960019047; Thu, 01 May 2014 09:00:19 -0700 (PDT) Received: from [172.16.30.39] (nat-08-mht.dyndns.com. [216.146.45.247]) by mx.google.com with ESMTPSA id a9sm35602203qgf.19.2014.05.01.09.00.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 09:00:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Abley In-Reply-To: <6.2.5.6.2.20140501081606.0c8d81e8@resistor.net> Date: Thu, 1 May 2014 12:00:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20140501081606.0c8d81e8@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/QdiEOO0soczV1X8N8SfSkmCscns Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 16:00:24 -0000 On 1 May 2014, at 11:20, S Moonesamy wrote: > I am forwarding this Last Call announcement (see below) as it is = something to do with DNS. >=20 > [...] >=20 >> The IESG has received a request from an individual submitter to = consider >> the following document: >> - 'Using ED25519 in SSHFP Resource Records' >> as Informational RFC I have read this document and believe it to be ready for publication. I = have no suggested improvements. Joe= From nobody Thu May 1 16:16:49 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E1F1A09FA for ; Thu, 1 May 2014 16:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBfETU6H2lof for ; Thu, 1 May 2014 16:16:36 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id A06A11A09E0 for ; Thu, 1 May 2014 16:16:35 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id F0D5F2383B1; Thu, 1 May 2014 23:16:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AAFB7160059; Thu, 1 May 2014 23:19:37 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7CCB6160057; Thu, 1 May 2014 23:19:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 556B715137E9; Fri, 2 May 2014 09:16:18 +1000 (EST) To: Joe Abley From: Mark Andrews References: <6.2.5.6.2.20140501081606.0c8d81e8@resistor.net> In-reply-to: Your message of "Thu, 01 May 2014 12:00:13 -0400." Date: Fri, 02 May 2014 09:16:18 +1000 Message-Id: <20140501231618.556B715137E9@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/0tziPbECnd-SSBCHCgjSVOvbZA0 Cc: S Moonesamy , dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 23:16:38 -0000 In message , Joe Abley writes: > > On 1 May 2014, at 11:20, S Moonesamy wrote: > > > I am forwarding this Last Call announcement (see below) as it is something t > o do with DNS. > > > > [...] > > > >> The IESG has received a request from an individual submitter to consider > >> the following document: > >> - 'Using ED25519 in SSHFP Resource Records' > >> as Informational RFC > > I have read this document and believe it to be ready for publication. I have n > o suggested improvements. Same here. Mark > Joe > _______________________________________________ > 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 nobody Wed May 7 17:26:24 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177D31A044D; Wed, 7 May 2014 17:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfhuWv58ubdH; Wed, 7 May 2014 17:26:01 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B60181A01B3; Wed, 7 May 2014 17:26:01 -0700 (PDT) Received: from mx1.yitter.info (unknown [187.185.71.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6C32A8A031; Thu, 8 May 2014 00:25:54 +0000 (UTC) Date: Wed, 7 May 2014 20:25:47 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20140508002544.GA7510@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/QObeaeGF0-L67-qhHun-eFgth_Q Cc: dnsop@ietf.org Subject: [dnsext] remarks on draft-vandergaast-edns-client-subnet-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 00:26:04 -0000 Dear colleagues, On the principle that I should work on something instead of talking about it, I had a look at draft-vandergaast-edns-client-subnet-02. I have a couple questions and remarks. First, I'm a little uncomfortable with "optimized reply" as the name for this. It seems to me that one could be getting this special authoritative reply for lots of reasons, though "optimization" is the usual one. I'd suggest a more neutral term; perhaps "origin-tailored reply" or something. The point is that the response you got is somehow scoped to some query originators and not others, and the document needn't take a position on whether that's good or bad. (This remark was mostly inspired by all the talk of "sub-optimal" later in the draft. As we know, some of these "optimized" cases are themselves sub-optimal. All the sub-optimal talk needs to be adjusted too.) Section 5.3 says In the cache, any resource record in the answer section will be tied to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK fields, as detailed below. Note that the additional and authority sections from a DNS response message are specifically excluded here. Now, imagine I'm querying for the NS for an in-baliwick DNS server, and I get back the answer, and it is somehow an optimized reply (as defined in the draft). (Note that I am not arguing this _should_ be something the authoritative server does, but it's implied as possible by the draft, so we better understand it.) In this case, the glue records that I get will in fact be optimized too. One is not allowed to cache them discriminately on the basis of client-subnet, however. I _think_ this is ok, because the right answer for the cache is to use additional section data for that query only, and throw it away, querying next time for the A and AAAA records if need be. Is that right? I'm pretty sure STRONGLY RECOMMENDED isn't an RFC 2119 term! (See section 5.3.) Also in 5.3, Replies coming from servers not supporting edns-client-subnet or otherwise not containing an edns-client-subnet option SHOULD be considered as containing a SCOPE NETMASK of 0 (e.g., cache the result for 0.0.0.0/0 or ::/0) for all the supported families. I think the "or" in the parenthetical is properly "and". No? Otherwise, this option implicitly divides all operations into v4-operations and v6-operations. If so, it needs to be made explicit somewhere. I'm concerned about the consistency between section 5.4 and this text in 5.1: The Stub Resolver may also add non-empty edns- client-subnet options to its queries, but Recursive Resolvers are not required to accept/use this information. In general, there is no way for a resolver to tell whether the request it just received is from a stub or from some other sort of resolver. So I don't see how that "not required" part and the restrictions in section 5.4 can all be true at the same time. Also, at the end of 5.4, there is, "Note again that an edns-client-subnet option with 0 address bits MUST NOT be refused." Surely that needs some scoping, like "MUST NOT be refused on the grounds of edns-client-subnet matching" or something. There are lots of reasons to REFUSE a query (like, for instance, the originating IP isn't allowed to query via you). Why is there no advice in section 9.1 for IPv6? Pick a number. /56 perhaps. It seems that there is nascent practice anyway among ISPs, and the draft ought to pick one. I'm really very happy to see a description of what the experiment is and what the conditions are to determine whether things have been successful. Section 12 still says that the option code is tentative, but perhaps that ought to be altered to indicate that, if the experiment is successful it might continue in use. Also, since this document is nearly a year old and the code point happened some time ago, I'm wondering whether there are any updates to the experiment. Maybe it's already yielded some results? I still think this is a worthy draft, and I think it ought to go ahead. It does alter the DNS protocol, so DNSOP is not the WG for it. I have included the DNSEXT mailing list, which is supposed to be where we discuss such changes, though I confess I have faint hope we'll actually do that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue May 13 13:37:08 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786A41A01BA; Tue, 13 May 2014 13:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN0R1lFrrM0G; Tue, 13 May 2014 13:37:01 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDFB1A019C; Tue, 13 May 2014 13:37:00 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKU3KCZmx0n4Rx94rTP4T7cKxaatFWCQIZ@postini.com; Tue, 13 May 2014 13:36:55 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s4DKaqs0005298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 16:36:53 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 May 2014 16:36:52 -0400 From: "Wessels, Duane" To: Andrew Sullivan Thread-Topic: [dnsext] remarks on draft-vandergaast-edns-client-subnet-02 Thread-Index: AQHPalQyhziamvyeTEW4tm4S/F6j2Js/RLaA Date: Tue, 13 May 2014 20:36:51 +0000 Message-ID: <6B025995-B49D-494A-9DCB-ADDC09C9A79F@verisign.com> References: <20140508002544.GA7510@mx1.yitter.info> In-Reply-To: <20140508002544.GA7510@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_B48C2839-A0FF-4602-846F-C542F7011F5E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/hWNeM5StGoh8sUnv_gSH8IHz0GU Cc: "dnsop@ietf.org" , "dnsext@ietf.org" Subject: Re: [dnsext] remarks on draft-vandergaast-edns-client-subnet-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 20:37:06 -0000 --Apple-Mail=_B48C2839-A0FF-4602-846F-C542F7011F5E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On May 7, 2014, at 5:25 PM, Andrew Sullivan wrote: > First, I'm a little uncomfortable with "optimized reply" as the name > for this. It seems to me that one could be getting this special I share this concern. If the mindset of "optimization" propagates into documentation and such, then every recursive operator out there will want to turn this on because, after all, who doesn't want their replies to be optimized? DW --Apple-Mail=_B48C2839-A0FF-4602-846F-C542F7011F5E 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTcoKJAAoJEGyZpGmowJiNnhMH/RH/ebd1+TcKXQquppvq2Xxr WYwMe/fEv6SyzmRo9YQLAMSn7LUcDTHVfMb2fqtW+OPCIvAaEm09ThRGghTO1cIQ ll9KmjImXaeFxvcMkTuPKbf0oTvmcmT+pIcS16g6kO+i+MQGqTCqihbZmTE3i5F2 wjsHzwo1IcQrqP0J4JnE9dYtLly/FjVzI3Xaf/ppV+poD/j2bFQ34nJ30/otWpw9 7mcWxjl8gYPTRGMd92ThmON/HNSGpSE6vUHIWYNlicOcI+n9UAV7P6eWRUsCNNOW IAMFSlpvBqhe0suyp8CGWvTQUyXu9qW6aX2mdIU8/uBp0cqX2HhYRAtRBsc9RUo= =Ijc0 -----END PGP SIGNATURE----- --Apple-Mail=_B48C2839-A0FF-4602-846F-C542F7011F5E-- From nobody Fri May 30 23:08:06 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491961A0773 for ; Fri, 30 May 2014 23:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkj6Zx6pxTUf for ; Fri, 30 May 2014 23:08:02 -0700 (PDT) Received: from ss.vix.su (ss.vix.su [IPv6:2001:559:8000:cb::2]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AE81A0776 for ; Fri, 30 May 2014 23:08:01 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:9979:dd28:128b:b91] (unknown [IPv6:2001:559:8000:cb:9979:dd28:128b:b91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.su (Postfix) with ESMTPSA id 25AE0EBCE3 for ; Sat, 31 May 2014 06:07:57 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <538971CD.3090109@redbarn.org> Date: Fri, 30 May 2014 23:08:13 -0700 From: Paul Vixie User-Agent: Postbox 3.0.9 (Windows/20140128) MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/RdF3Vb-lM8KBBcsnwmatjEU8I2M Subject: [dnsext] icann rssac caucus X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 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, 31 May 2014 06:08:04 -0000 Greetings, If you are interested in participating at ICANN's Root Server System Advisory Committee (https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly read the relevant information and Caucus document published at https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of interest to rssac-membership@icann.org The RSSAC executive is working on publishing the final version "Procedures documents" and at the moment is establishing the Caucus and with a few work items ready to be discussed by the Caucus. If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-membership@icann.org. Kind Regards, Kaveh Ranjbar, RSSAC Membership Committee Chair Tripti Sinha, RSSAC Membership Committee Member Paul Vixie, RSSAC Membership Committee Member